Author: Martin

I recently visited a friend of mine in Paris who is now working for a N2NSoft, a company with quite an interesting product: Before deploying networks or even before applying for a license, operators need to know how much to spend on the wireless and fixed infrastructure to see if their business model is sound. The cost and number of base stations, routers, fiber links, etc. mainly depends on the number of users, what kind of applications their are using, if they are mobile or not, how good the coverage of the network is, etc. etc. As there are so many variables, simple calculations might give a ballpark estimation of the costs to come. However, this is not good enough for financial calculations.

If one could simulate the user behavior, however, a prediction could be much more accurate. This is just what the company has set out to do with their flagship product called NetScale. Simulating the behavior of a couple of users is simple in terms of computing power. So far, however, processing time of most algorithms used grow exponentially with the number of simulated users. So simulating more than a few users gets tricky very quickly. It looks like N2NSoft has found a solution to this with an algorithm developed at the INRIA, one of the top French research institutions. Instead of computing time growing exponentially, their algorithm scales linearly. This is the dream of any mathematician.

Over lunch, we played with a network simulation of 250 nodes and 50.000 users. Each user was simulated individually and the simulated network had all kinds of different users from stationary notebook usage to moving hand-held eMail retrieval and ring-tone downloads. For each user, the simulation shows the TCP/IP traffic flow in real time, packet losses, retransmissions and overall performance on every link. To see the effect on end user throughput when capacity on a link is reduced or increased is simple as everything is computed in real time. Click on the picture on the upper left, it shows a bit of the GUI and simulation output. More pictures and info can be found here.

Thanks for the interesting lunch break, Pierre, I keep dreaming at night of 50.000 mobiles all accessing the network simultaneously 😉

In the previous entry on this topic I’ve given an overview of how to use a Linksys WRT54G Wireless LAN router OpenWRT, Kismet and Wireshark for Windows for wireless network monitoring and analysis purposes. This blog entry takes a look at the steps necessary to install the required software on the router.

The first step of the process is to buy a wifi router which supports OpenWRT, an alternative and free of charge Linux operating system for wifi routers. The routers supported by OpenWRT can be found here. I decided to buy a Linksys OpenWRT54GL as it offers enough RAM and Flash to run OpenWRT and has enough space for additional software to be installed later on. The price of the router was about 60 euros.

Installing OpenWRT

Once the router arrives, I suggest to use the built in software first to configure it as a Wireless Access point to verify the hardware works as expected. Once done, the router should be reset to run with the original out of the box settings. There are a number of different OpenWRT images depending on the router and router version. This page on the OpenWRT Wiki explains how to select the right image, from where to download it, and how to install it on the router. I chose to install this standard image for the Linksys WRT54G(L). In essence installing the OpenWRT firmware image is very simple by using the ‘update firmaware‘ functionality of the web interface of the original firmware. Be sure to read the installation page linked above for the fine print.

Installing a better Web Interface

After a router restart, open another browser window and access the router again. In a first step, select a new password. Afterwards, configure the router via the web interface so it is able to access the Internet. This is necessary as the software packages which are installed next are directly installed via shell commands on the router.

As the OpenWRT web interface is quite bare I suggest to install X-WRT next, a much improved web interface. This is done via a secure shell (SSH) session. This requires a Telnet/SSH program for Windows. I recommend using Putty.

Important note: Use SSH (port 22) to log into the router, telnet is not supported for security reasons. To log in use ‘root’ as user name and whatever password you’ve initially configured via the web access, even if that password is associated to a different user name.

Once you have shell access to the router, ensure the router can reach the internet by pinging a public IP address (e.g. ‘ping www.google.com‘).

Next, install X-WRT as follows: First ‘ipkg update” has to be typed in to load descriptions for additional software to the router. Once done, ‘ipkg install webif‘ installs X-WRT. Once the command has run successfully, the new web interface is available.

Before proceeding to the next main step one further thing should be done: On the web interface, select Wifi configuration and install the NAS package required for WPA/WPA2 encryption later on. This is  done by pressing the corresponding button on the wifi configuration page. Once done, the wifi setup page looks like shown in the picture on the left at the beginning of this paragraph.

Installing Samba/CIFS package

The next major step is to install a driver on the router to be able to mount a Windows directory. This is needed as the Kismet dump files which contain the intercepted packets can get quite big and there is not enough space on the router to store them. This OpenWRT wiki entry describes the details. In short: ‘ipkg install kmod-cifs‘ downloads the driver. ‘insmod cifs‘ then install the driver into the Linux kernel. Both commands only have to run once as the driver insertion is permanent and survives reboots.

Once done, create a new directory on the router (e.g. ‘mkdir /martin‘) which will be used in a next step as a mount point. Afterwards, share a drive on the Windows PC connected to the router and mount it on the router with a command in the shell that should look like this: ‘mount -t cifs //192.168.70.63/testshare /martin -o unc=\192.168.70.63testshare,ip=192.168.70.63,user=martin,pass=xxxyyyzzz,dom=workgroup‘.

192.168.70.63 is the IP address of the router and ‘testshare’ is the directory I’ve opened for network sharing. Make sure the user name and password given in the command are correct. If you don’t know the domain of your PC it’s probably the default domain name ‘workgroup’. If the command succeeds a new command prompt without a further message appears.

Change the directory to the mount point and verify the share is mounted correctly by putting a couple of files into the Windows directory with the file explorer and by doing an ‘ls -l‘ on the router. They should then be visible on the router.

Note: ‘mount’ doesn’t give very detailed error messages in case something goes wrong. In case you encounter problems, make sure first of all you have set the Windows firewall to allow network and printer sharing on the local LAN.

Note 2: The share has to be remounted after the router has been rebooted.

Installing Kismet

Hold your breath we are almost there now. The final step is to install Kismet. This is done by typing ‘ipkg install kismet-server‘ and ‘ipkg install kismet-client‘. Once done, change into the directory in which the share of the PC is mounted and type ‘kismet_server‘ (note: underline!). Kismet will then start and output a number of messages as shown on the left. Open a second ssh window and start the client by typing ‘kismet_client‘. The client automatically connects to the server and displays an overview of the number of networks found, packets received, etc. On the PC take a look at the shared directory. You should see a number of new files created by Kismet. The most important one is the .dump file which contains all packets received by Kismet. Once enough packets are collected, press ‘CRTL-C’ in the kismet server ssh window to stop the server. Afterwards, rename the ‘.dump’ file into ‘.pcap’. If you’ve already installed Wireshark on the PC you can now double click on the file to open Wireshark to display the captured frames. If you haven’t installed Wireshark so far, download it from here.

Here we go, that’s it! Not quite a solution that works out of the box straight away but with some prior Wifi configuration experience and a bit of Linux experience not to difficult to do. Have fun!

I read an interesting article today about the current power consumption of the worlds mobile networks. The number is quite staggering. According to the article, current mobile networks consume about 43 billion kilowatt hours of energy a year.

If one assumes 2.5 billion mobile users, that would be 1.4 kWh a month or 46 Watt hours a day or 2 Watt of average power per user. To set this into relation: My personal power consumption at home per month is about 200 kWh. Thus, depending on how you look at the 43 billion kWh the number is quite big or small.

Here’s another number from another source that says that German mobile networks currently use about 1 billion kWh per year. Divided by let’s say 70 million subscribers the numbers per user per month match quite well.

So how many power plants do you need for all networks worldwide? 43 billion kWh broken down to average power is 43 billion kWh / (365 days * 24h) roughly equals 5.000 Megawatts = 5 Gigawatts. That’s the energy which is produced by about three to four big nuclear power generators (source)

Taking traces in a Wireless LAN can be quite a tricky thing if you are using Windows. Except for a few expensive programs which can do the job, other free tools like Wireshark can only trace what the network driver forwards to the operating system. Unfortunately, Windows network drivers only forward pseudo Ethernet frames to the OS and hide all the nitty gritty Wireless LAN details. An alternative to tracing a Wireless LAN with your PC is to let an off the shelf Wireless LAN access point record all packets and save them to a file which can then be analyzed on the PC. Cost of the solution: 60 euros and a bit of time to set it up.

In this and the next couple of blog entries I’ll give an overview of how to collect packets in a Wireless LAN and how to analyze them on a Windows PC with such a setup. If you don’t know much yet about the basic technology behind Wifi, I can warmly recommend chapter 4 of my book.

The Wifi tracing environment consists of the following components:

• A PC or notebook running Windows with an Ethernet port.
• A Linksys WRT54G or WRT54GL wifi router (picture above, for details see below). The WRT54G sells for around 50-60 euros on eBay. Several hardware versions exist, not all of them are suitable. For details, see the next blog entry.
• OpenWRT, a free Linux operating system for the wifi router (open source)
• X-WRT, a better web interface for OpenWRT (open source)
• Kismet for OpenWRT (open source)
• CIFS driver for OpenWRT to be able to mount a directory of your windows computer on the router for file export (open source)
• Wireshark for Windows (open source)
• Putty for Windows, a free telnet/ssh shell for Windows

With this setup, tracing a Wirless LAN can be done as follows: In a first step, the native software of the wifi router has to be replaced with OpenWRT, X-WRT, Kismet and a CIFS driver. Once the setup is running, Kismet is used on the router to collect all 802.11 wifi packets the router receives and to save them to a file. As there is not a lot of room on the router for the file it needs to be stored elsewhere. This is done connecting the router and a Windows PC with an Ethernet cable and by mounting a Windows directory on the router. No extra software is required on the Windows PC. On the wifi router the CIFS driver is used to mount the directory. The file Kismet creates in the shared directory can then be analyzed using Wireshark for Windows. The picture on the left shows how Wireshark decodes an 802.11 beacon frame recorded by Kismet.

Part 2 of this series will pick up at this point and explain how to get started, which wifi routers are suitable for this project, how the software is installed, how the Windows directory is mounted on the router and how to get started with the router.

I’ve been writing on this blog for quite some time now mostly on wireless technical topics and I am enjoying every post. For me, this blog has become an extended notebook that helps me to focus and explore new ideas and topics. There are two reasons for this musing on the reasons why I run this blog:

Firstly, this is my 200th blog entry and ideas are coming faster than I can often write them down. I am very much looking forward to the next 200 entries :-). Secondly, Rudy de Waele has asked me if I wanted to broaden my blogging activities and join forces with him and Yasmine Abbas at m-trends. As we are looking at similar topics all from a different angle, working together could create an interesting combination and open new horizons.

I very much like the idea and I am looking forward not only to your comments to future thoughts here at mobilesociety but also over at m-trends. Off we go, here’s my first article abut the four axis of wireless success.

Over the past couple of days I’ve experienced some problems with large file downloads over Wifi. Regularly, download speeds decreased to almost zero for a couple of seconds before recovering. Today I found the culprit: My new Bluetooth USB stick in combination with the Nokia PC suite.

The 100 mW Bluetooth stick I bought a couple of days ago is used by the Nokia PC suite every now and then to check if one of my phones is in the neighborhood. As Bluetooth and Wifi use the same frequency band they can interfere with each other. The PC suite tries to establish a connection to the phones about every 20 seconds. When the Bluetooth stick attempts to create a Bluetooth connection the Wifi connection is pretty much wiped out. On the first picture on the left it can be seen that the Wifi throughput measured by NetMeter drops to 0 just when the HCI Create Connection Event is sent to the BT stick.

Picture two shows the situation traced with a Wifi network tracing tool. At the time of the interference the access point tries to deliver a packet (4043) but does not get an 802.11 acknowledgment frame from the notebook. It tries three more times before giving up. It then tries to send the next packet (4047) which equally fails. The third packet (4051) gets an ack from the notebook so that transmission was o.k. That doesn’t help much, however, as two packets are missing so the TCP stack immediately stalls and requests a retransmission from the source (not shown in the picture).

I can break the pattern by transmitting a file to the phone over Bluetooth. While the file transfer is in progress the Wifi download returns to normal. Once the file transfer has finished the Wifi connection is interrupted again in the regular pattern. This is most likely because once the Bluetooth connection is established power control kicks in which reduces the Bluetooth power and thus the interference to the Wifi transmission. As both my Bluetooth stick and the remote device are BT 2.0 capable it is also possible that the BT stack recognizes the Wifi interference and starts excluding the Wifi band from the hopping sequence. Maybe it’s even both, hard to tell.

Two remedies come to mind: For the moment I have deactivated Bluetooth in the PC Suite which promptly brings my Wifi transmissions back to normal as the Wifi stick no longer attempts to connect to the phones every 20 seconds or so. I think I’ll bring the 100mW stick back to the shop and see if a 10mW stick creates less interference during connection establishment. I’ll keep you posted.

I was quite surprised that the Nokia PC Suite can connect to several phones simultaneously, e.g. over Bluetooth. Take a look at the picture on the left. When moving the mouse pointer over the PC suite tray bar icon it shows that both phones are connected.

Third Party Applications Support

It even works for third party applications! I use Handysafe on the PC and on a N93 to store my passwords. When synchronizing a window appears in the application to ask the user with which of the phones currently connected to synchronize. Very nice!

Auto Connect

And another nice functionality: The Bluetooth connections to a phone is automatically established whenever it is close to the notebook. That’s a nice feature as I can now access the memory card to transfer files without going through a connection procedure. I’ve used if for a couple of days now and it seems that it doesn’t have a big impact on battery lifetime. That’s probably because the Bluetooth connection is not active all the time and the PC Suite just checks every now and then that the phone is still there.

Also, the permanent virtual connection works nicely alongside other Bluetooth connections I establish every now and then to the mobile phone, e.g. with my foldable Bluetooth keyboard.

But be careful what you wish for: I detected that in conjunction with a 100mW Bluetooth stick, this setup wreaks havoc on my Wifi network. More about that in the next post.

This ‘Deep Inside the Network episode’ focuses on UMTS security mechanisms and enhancements over GSM. Like the previous ‘Deep Inside’ articles I expect the target audience to be rather small. Nevertheless, I decided to post it anyway as I haven’t found this information in a similarly compressed form anywhere else.

Introduction

Like GSM, UMTS has strong security measures which are described in detail in [1] to prevent unauthorized use and eavesdropping on user data traffic and conversations. Over the years, a number of weaknesses have been found in the way GSM protects networks. These have been addressed with a number of enhancements in UMTS. 

These main ones are:

• The GSM circuit switched part does not protect the link between the base station and the BSC. In many cases, microwave links are used which are vulnerable to third party monitoring.
• GSM allows man in the middle attacks with equipment that masquerades as a GSM base station.
• The ciphering key length used in GSM is 64 bits. While having been secure when GSM was first developed back in the early 1990’s it is considered insufficient today. A number of weaknesses with the A5/1 stream cipher have been detected such as described in [2] which allow to decrypt a voice conversation with the appropriate equipment.

UMTS Authentication Vector vs. GSM Authentication Triplet

UMTS addresses these weaknesses in a number of ways. Like in GSM, a one pass authentication and key agreement (AKA) procedure is used with immediate activation of ciphering after successful authentication. When a mobile station first connects to the network it sends its identity (IMSI or T-IMSI) which is stored on the SIM card. In case the subscriber is not known by the MSC/VLR, which is responsible for circuit switched connections, or the SGSN, responsible for packet sessions, authentication information has to be requested from the authentication center which is part of HLR (cp. figure 1.14). In addition to the random number (RAND), the expected response (SRES, referred to as XRES in UMTS) and the ciphering key (Kc, referred to as CK in UMTS) which are already known from GSM, two additional values are returned. These are the integrity key (IK) and the authentication token (AUTN). Together, these five values form an authentication vector.

Authentication Token and Sequence Numbers:

The authentication token (AUTN), which is new in UMTS, serves two purposes. The AuC generates the AUTN using a random number and the secret key of the subscriber. It is then forwarded together with the random number to the mobile in a mobility management (MM) authentication request message. All other values are retained at the MSC/VLR or SGSN for the moment. The mobile station then uses the AUTN to verify that the authentication procedure was initiated by an authorized network. The authentication token additionally includes a sequence number which is increased in both the network and the mobile after every successful authentication. This prevents third parties from using intercepted authentication vectors for fake authentications later on.

Like in GSM, a UMTS mobile station has to generate a response value which it returns to the network in the MM authentication response message. The MSC/VLR or SGSN then compares the response value to the expected response value (XRES) which it has received as part of an authentication vector from the HLR/AuC. If both values match, the subscriber is authenticated.

128 Bit Ciphering Key

In a further step, ciphering between the mobile and the network is activated by the network by sending a RANAP Security Mode Command message to the RNC. This message contains the 128 bit ciphering key. While in GSM ciphering for circuit switched calls is a function of the base station, UMTS calls are ciphered by the RNC. This prevents eavesdropping on the Iub interface between the RNC and the base station which is vulnerable to interception especially if transported over microwave links. A RRC security mode command message informs the mobile that ciphering is to be activated. Like in GSM the ciphering key is not sent to the mobile as this would compromise security. Instead, the mobile calculates the ciphering key itself by using, among other values, its secret key and the random number.

Message Integrity Checking

Security mode command messages do not only activate ciphering but also integrity checking for signaling messages, which was not done in GSM. While ciphering is optional, integrity checking is mandatory to activate after authentication. Integrity checking is performed for RRC, CC, SM, MM and GMM messages between the mobile station and the network. User data on the other hand has to be verified by the application layer if required. To allow the receiver to check the validity of a message a integrity stamp field is added to signaling messages. The most important parameters for the RNC to calculate the stamp the content of the signaling message and the integrity key (IK) which is part of the authentication vector received from the authentication center. Integrity checking is done for both uplink and downlink signaling messages. In order to perform integrity checking for incoming messages and to be able to append the stamp for outgoing messages, the mobile station calculates the integrity key itself after the authentication procedure. This is done by the SIM card by using the secret key and the random number which was part of the authentication request message. This way, the integrity key is also never exchanged between the mobile station and the network.

Key Lifetime

Keys for ciphering and integrity checking have a limited lifetime to prevent attempts to break the cipher or integrity protection by brute force long duration monitoring attacks. The value of the expiry timers are variable and are sent to the mobile station at connection establishment. Upon expiry, a new set of ciphering and integrity keys are generated with a re-authentication between the mobile and the network.

Authentication, ciphering and integrity checking are performed independently for the circuit switched and the packet switched connections. This is because the MSC handles circuit switched calls while the SGSN is responsible for packet sessions. As these devices are independent they have to use different sets of authentication vectors and sequence numbers.

New Algorithms

UMTS also introduces new algorithms to calculate the different parameters used for authentication, ciphering and integrity checking. These are referred to as f0-f9. Details on the purpose and use of these algorithms can be found in [1].

GSM SIM Card Backwards Compatibility

On the user side, all actions which require the secret key are performed on the SIM card to protect the secret key. As older GSM SIM cards are not able to perform the new UMTS authentication procedures, a backwards compatibility mode has been specified to enable UMTS mobile stations to use UMTS networks with an old GSM SIM card. When the mobile station detects an old GSM SIM card it informs the network during connection establishment that a GSM backwards compatible authentication procedure is required. Instead of requesting an authentication vector from the authentication center, the MSC/VLR or SGSN will instead request a GSM compatible authentication triplet. The UMTS ciphering and integrity keys are then computed by the mobile station based on the GSM ciphering key Kc (note: not the secret key!) which is returned by the SIM card. As the SIM card is not able to process the authentication token, it is not sent by the network during authentication. On the network side the MSC/VLR and SGSN are responsible for computing these values. To be backwards compatible, the mobile informs the network during connection establishment that a SIM instead of a USIM is used. The network will then request a standard authentication triplet from the HLR/AuC.

Further Reading

If you are also interested in other topics concerning GSM, GPRS, UMTS, Wifi, WiMAX and Bluetooth, take a closer look at the book to this blog “From GSM to LTE-Advanced: An Introduction to Mobile Networks and Mobile Broadband“, which you can find here.

References:

[1]    3GPP, „3G Security ; Security Architecture“, TS 33.102

[2]    Patrick Ekdahl and Thomas Johansson, „Another Attack on A5/1“, IEEE Transactions on Information Theory, Vol. 49, No.1, January 2003, page 284 – 289

Update 22. Feb. 2016: Spelling errors corrected, link to book updated

Blogs, news web sites, tech tips are all on the web these days. Books, however, are far from being pushed to the side by it as they can explore topics in a much deeper way than articles on the web. So if you are like me and like to read a good book on telecoms and communication, the Telecoms Book Blog might just be the right resource that will help you to find your next book. Check it out, I am listed as well 😉