Author: Martin

I'm always a bit shocked when I hear people saying that “Google and others track you anyway on your smartphone and there is nothing that can be done about it”. I sense a certain frustration not only on the side of the person who's made the statement. But I obviously beg to differ. As this comes up quite frequently I decided to put together a blog post that I can then refer to with the things that I do on my Android based device to keep my private data as private as possible.

The Three Cornerstones to Privacy

In essence, my efforts to keep my private data private is based on three cornerstones:

• As few apps on the device as possible that communicate with servers on the Internet without my consent.

• Allowing access to private information such as location, calendar entries, the address book, etc. to specific apps while blocking access for all others by default.

• Preventing communication of apps with servers on the Internet that I would like to use. Amazon's Kindle reader app is a prime example. It's a good app for reading books but if left on it's own it's far too chatty for my taste.

In some cases, implementing these cornerstones in practice is straight forward while other things require a more technical approach. The rest of this blog entry now looks at how I implement these cornerstones in practice.

CyanogenMod

For a number of blocking and monitoring approaches described below it's necessary to get root rights on the device. This is nothing bad and there's a difference between rooting and jail breaking as I described in this blog post. One way to conveniently get root rights is to install an alternative Android OS on the device. CyanogenMod is my distribution of choice as it is mainstream enough for good support and stability and has no Google apps installed by default. As a user, I can then decide to install only those Google apps I require such as the Google Play store. Apart from the app store, the Play Services framework and the Google keyboard there's little else Google specific I have installed. Sure, there's additional stuff in the basic OS that wants to talk to Google servers but these parts can also be silenced as shown below.

Privacy Guard

By default, CyanogenMod is shipped with the 'Privacy Guard' feature that allows to restrict access on a per app basis to lots of different sources of private information such as the calender and address book, the GPS receiver, etc. So even if an app requires access to the address book to install properly, access can still be removed later on. A good example is the app of the German railway company which wants to have access to my address book and my location so it can help me to find nearby stations easier. It's a noble goal but I don't want to it to have access to my private data. With Privacy Guard restricting access the app still works but only sees an empty address book, doesn't get a position fix when it asks for it without crashing or acting up in strange ways. In practice I've configured Privacy Guard to ask me when newly installed apps want to access any kind of private information so I can either allow or deny it temporarily or permanently so I won't be bothered by requests anymore in the future.  Also, I went through the list of already installed apps and removed access rights for many of them to information sources I don't want those apps to have access to.

Using an Alternative Web Browser

Most people just use Google's default Chrome browser on an Android device and are thus freely sharing everything they do on the web from their mobile device with Google. And yet is is so easy to install an alternative browser such as Opera or Firefox. Personally I prefer Opera even though it is not open source. But at least it does not talk to Google all the time and it has a great text-reflow feature that I personally miss in all other alternatives I tried so far.

Using an Alternative Search Engine

Most web browsers, even alternative one's use Google for web searches by default, giving Google yet another way to collect private information about users.  But it's easy to use other search engines such as DuckDuckGo, Yahoo/Bing etc., I'm still giving away private information through my search queries but at least it ends up in other hands.

Blocking Unwanted Communication

Despite using Privacy Guard, alternative web browsers and search engines there's still a lot of communication going on between apps and servers of Google, Amazon and others. The only way to control these short of not installing them is to block communication to those servers. A way to conveniently do this is to block communication to them via the 'hosts' file. Modifying the 'hosts' file requires a terminal program and root access, both of which come packaged with CyanogenMod. I've put my hosts file and scripts to activate and deactivate blocking on Github so you don't have to start from scratch. Have a look at this blog post for details. With this in place there's very little traffic going to servers I don't like it to go and further down in the post I describe how I occasionally check that this is still the case.

GPS-only Location

While it is admittedly convenient to send information about Wi-Fi networks at my location and the current Cell ID to Google's location services for a quick location fix it also allows Google to track me. Yes, they say the data is processed anonymously but I still don't like it. And I don't have to because GPS-only location provides a quick location fix as well these days. Unfortunately, some devices use Google's Secure User Plane Location (SUPL) server and include my subscriber id (IMSI) and location information in the request. Many devices, however, use other services to help the GPS chip to find the satellites more quickly which seem to be less nosy. For details have a look at the the blog posts here and here.

Owncloud for Synchronization

Naturally I don't want to share my address book and calendar with Google, Microsoft or any other big company for that matter. As a consequence I only used a non-synchronized calendar on my PC and an address book on a smartphone. And then Owncloud came along and made me make peace with 'the cloud', as my cloud services are at home. Since having an Owncloud server at home I enjoy calendar and address book synchronization between all my devices without the need to share my data with a cloud service provider.

Open Street Maps

Yes, and you might have guessed by now I also don't want Google to know where I'm going. I thus do not use Google Maps for street or car navigation. Instead I use Open Street Maps for Android (Osmand). It's a great app and I used it for car navigation for the past two years now. Better still, all maps are on the device so my smartphone doesn't have to frequently download maps data from the web while driving. The downside is that I don't have traffic jam notifications but I'm willing to trade that for my privacy.

Mobile eMail

Needless to say that Google is not my email provider either. Instead I use a medium sized German company for the purpose and Thunderbird on the PC. On my Android smartphone I use the open source K9 email program to manage my emails. It's forked from Google's email program and works pretty much the same way, except it's not talking to Google of course.

Music and Videos On My Mobile

Again, I prefer the open source VLC player to other pre-installed products, even to CyanogenMod's Apollo. It plays just about any audio and video format I throw at it without the need to talk to anyone on the web.

Seeing is Believing

And finally, it's important to check what kind of unwanted communication is still going on in the background after having taken the steps above. This can then be used to update the 'hosts' file or take some further measures. Tracing IP traffic to and from the device can be done in several ways. One way is to use a Wi-Fi access point and connect it to the Internet via the Ethernet socket of a PC which is configured for Internet sharing. With Wireshark on the PC, all traffic from the smartphone via the Wi-Fi access point can then be monitored. Another approach is to use a Raspberry Pi as a Wi-Fi access point and then use tcpdump running on the Pi and Wireshark running on a PC that is also connected to the network to inspect the phone's data exchange. Another interestion option is to run tcpdump directly on the smartphone and inspect the resulting dump file with Wireshark on a PC. This way, one can even collect IP packets that are transferred over the cellular interface.

Final Words

Purists will argue now that even when all measures are taken things are far from perfect. I tend to agree but there far less of my private data being extracted from my smartphone without my consent or, at least, without my awareness.

When it comes to spectrum, current cellular networks that are designed well can still keep up with the ever rising demand for bandwidth. In addition, not all of the spectrum below 3 GHz that has been assigned to cellular operators is used so capacity can be further increased by adding additional carriers per base station for a few years. In addition, there is still spectrum below 3 GHz that could be assigned to cellular networks in the future but compared to what's already assigned it is not that much. So sooner or later, alternatives are required to keep up should bandwidth demands continue to grow at current rates of 50-80% per year.

Small Cells to Escape The Bandwidth Crunch On High Frequencies

There are a couple of options to escape the dilemma: Smaller cell sizes and spectrum in higher frequency bands. Smaller cell sizes and the use of licensed spectrum allow a higher re-use factor and hence increase the overall capacity of the network. There is also no way around very small cells when licensed or unlicensed spectrum beyond 3 GHz are considered for future use as the higher signal attenuation limit practical cell sizes to a few tens of meters from the cell's center. So one way or another, going beyond current network capacity by an order of magnitude requires smaller cells. How that can be done economically is a matter of debate and I won't dwell on this particular point in this blog post.

What I would like to take a closer look at today, however, is the potential use of the license free 5 GHz band which is pretty much exclusively used by Wi-Fi today. So while the Wi-Fi camp is probably not very happy about the LTE camp considering this band, it is a logical evolution of the LTE ecosystem  and the 300+ MHz of available spectrum in the band at zero cost is quite irresistible as well.

A number of industry players are doing quite a lot to push the idea in the media at the moment. Even 3GPP published an article back in September 2014 on their web site stating that LTE in the license free 5 GHz band, referred to as LAA-LTE (License Assisted Access LTE), is  seen as a major RAN feature for 3GPP Release 13. [http://www.3gpp.org/news-events/3gpp-news/1628-rel13].

What is License Assisted Access?

So why this strange name “License Assisted Access”? The 3GPP Study Item on the topic (see links below) is quite clear that the aim, at least initially, is not to have independent LTE cells in the 5 GHz band. Instead, a primary cell transmitting on a carrier in a licensed chunk of spectrum a network operator has paid for is complemented with an additional LTE carrier in the unlicensed 5 GHz band. The Study Item even goes as far as saying that in a first instance, the 5 GHz band shall only be used for downlink transmission, i.e. as a Secondary Cell (SCell) in a classic Carrier Aggregation (CA) configuration. All signaling and control information is only sent on the Primary Cell (PCell) which is operated in a licensed band. I'm not quite sure why that limitation has, at least for now, been put into place but it sounds like there is a fair amount of politics involved to appease some players with a vested interest in Wi-Fi. What such a setup would of course do is to keep a cellular signaling link in place all the time so an ongoing data transfer can quickly be pulled away from a LAA-LTE carrier back to the primary carrier that potentially covers a larger area when the signal deteriorates.

And this immediately brings us into the domain of the various HetNet (Heterogeneous Network) and CoMP (Coordinated Multipoint) features that have been specified in recent 3GPP releases but are not used in practice so far. So perhaps at the beginning small eNodeBs devices may transmit both the PCell and SCell parts. But I am sure at some point the industry might get more daring and also think about a split between the PCell being transmitted in licensed spectrum from an overlay macro cell while the SCell using unlicensed spectrum is transmitted from a small cell. An interesting aspect of such a scenario would be that a small cell that only uses unlicensed spectrum is easy to set-up as the site does not have to be registered as a cellular transmitter. After all, it's only using unlicensed spectrum and has to adhere to the same transmit power limitations and regulations as Wi-Fi access points.

Dealing with Interference and Being a Fair Player

Obviously as someone operating a Wi-Fi access point in the 5 GHz band at home for high bandwidth media streaming I'd be very unhappy if a nearby LAA-LTE cell would significantly interfere with my transmissions. Fortunately there is enough space in the 5 GHz band, at least until 160 MHz Wi-Fi channels defined by 802.11ac replace the 40 Mhz and 80 MHz channels used by 802.11n and 802.11ac products today, so networks can go out of each other's way. LAA-LTE carriers will be limited to 20 MHz channels but Carrier Aggregation (CA) would allow to bundle several channels in addition to the PCell channel in a licensed band. Today, 2×20 MHz Carrier Aggregation in licensed bands are used in practice and 3×20 MHz Carrier Aggregation is just around the corner. By the time LAA-LTE might be ready for deployment, perhaps in the 2018-2019 timeframe, it might be even more.

Also, the Study Item promises to have a close look at how a “Listen before Transmit” scheme can be implemented for the LAA-LTE cell so it can detect Wi-Fi networks in the same spectrum and either change to a different section of the band, reduce it's transmit power or to coordinate transmissions with the Wi-Fi networks it detects. The promise is that a LAA-LTE carrier would no more interfere with a Wi-Fi network than other Wi-Fi networks in the area. A nice promise but a heavily loaded nearby Wi-Fi network would interfere quite a lot with my own Wi-Fi network.

It's going to be interesting to see how this particular part will be standardized. Today, an LTE cell does not look out for interference and uses the licensed spectrum assigned to a carrier whenever it likes. Wi-Fi on the other hand has an interference and collision detection scheme with backoff times and retries. So if you will, LTE without any enhancements is not really a fair player when it comes to competing for the same spectrum with other transmitters in real time because it did not have to compete for access to a channel so far. Also a LAA-LTE cell has to take care that it doesn't interfere with a LAA-LTE cell in 5 GHz band of another network operator that has also decided to put a small cell in the area.

Why Compare Spectral Efficiency of LTE vs. WiFi?

Sure, one could use Wi-Fi access as part of a cellular network but there have been so many approaches to include Wi-Fi access into a cellular network infrastructure that have failed that it's not worth to think about yet another flavor. What makes LTE so attractive over Wi-Fi for cellular use is not its spectral efficiency but that LTE is a cellular technology while Wi-Fi is a hotspot technology without mobility in mind. So while Wi-Fi is great for homes, hotels and offices for stationary or nomadic Internet use, it can't compete with LTE in full mobility scenarios in which it is important to have automatic subscriber authentication, integrated backhaul and seamless mobility to and from larger macro cells. Also, Wi-Fi is not specified 3GPP so they have little influence over potential enhancements required to fully integrate it into an LTE network. As I said above, it's been tried before…

Timing

To make sure I still remember how it this activity started here are some dates. From what I can tell, the Study Item started in December 2014 and Ericsson envisages the study to be finished by mid-2015 with the specification to be finished mid 2016. Deployment usually takes 2-3 years after that.

Background Reading

And here are a number of great links to the details:

• Felllow blogger Zahid Ghadialy already picked up on the topic back in June 2014. Zahid also links to his blog posts on LTE-U (-Unlicensed) that show activity around using LTE in the 5 GHz unlicensed band as far back to December 2013.

• And here's a link to the report from the 3GPP workshop on 'LTE in Unlicensed Spectrum” held in June 2014 in Sophia Antipolis.

• The LAA-LTE Study Item description from September 2014, RAN#65, Edinburgh.

• And the final Study Item Description as approved in December 2014 in the 3GPP RAN#66 plenary meeting.

• The latest document is TR 36.889, created in December 2014 at RAN#66 that will be updated continuously to hold the result of the study item.

After updating an app recently on my CyanogenMod based Android device that requires GPS information I was surprised and admittedly also a bit annoyed that it wouldn't access the GPS receiver anymore. When looking at the release notes I saw that the app changed from Android's legacy GPS API to the Google Play GPS API but still offered an option in the settings to change back to the legacy API. And indeed, after switching to the legacy API everything worked again. But why wouldn't the Google Play location API work on my device?

It took me a while to figure it out but I finally realized that half a year ago I activated CyanogenMod's Privacy Guard features for the Google Play services app as at the time I had no idea what the app that appears in the app overview actually does and thus saw no need to let it have access to my private data. As it kept asking for permissions I set Privacy Guard to just block requests without user notifications. And since I use alternatives to most Google apps I haven't had a problem with that setting until today.

On the left are two screenshots that show CyanogenMod's Privacy Guard in action. The first one shows the check box to activate the protection mechanism on a per app basis. The second screenshot shows the top of the list of access permissions that can be granted on a per app basis either always, on request or never.

So while my experience was a bit unpleasant, the positive side is that is showed that Privacy Guard does what it is supposed to do.

When recently contemplating about the use of frequency bands for LTE in different parts of the world I realized that there have been different approaches: In the US, network operators opted for deploying LTE in the 700 MHz area and have only recently started to use higher bands such as the 1700/2100 MHz band for LTE services. In Europe most carriers started with the 1800/2600 MHz band but quickly also opted for the 800 MHz band to push nation wide coverage. When I was in China recently, I noticed that I could only trace deployments in the 1900+ MHz range (e.g. TDD bands 39-41 as described on Wikipedia) but nothing below that. In retrospect, I find it quite surprising that they haven't started their rollout on lower frequencies to get a large footprint in their not so small country.

Whenever I'm in the UK I can't help the feeling that the mobile networks are far away from the coverage and performance I've come to expect in Germany and Austria. But maybe it's just me?

No it's not as P3, who test the German, Austrian and Swiss networks for the 'Connect' magazine now also has results for the UK. For details see the PDF that can be download here. Looks like much hunch was indeed correct. While the winner in the UK would barely make it to the 3rd place in Germany, it would be the worst network by a wide margin in Austria and Switzerland. Datarates on average across the board are only a fraction what they are in other countries and voice call setup success rates are several percentage points away from those in other countries. Doesn't sound like much at first perhaps, but take it from me, network engineers are fighting for tenths of a percent in this area.

The report comes to the conclusion that there is a lot of room for improvement but at least the latest technology is already used, so if there is a will there is a way. That makes one wonder why the result is so different in the UK!? Many people attribute it to the cut throat pricing in the UK. While I'm convinced that this is part of the answer, it can't be the whole story as prices in Austria have been at very low levels for years now as well (take my recent experience in Austria as a good example) but network performance of all remaining network operators there is still excellent.

These days I often wished I could disable GSM in my phone and live with the occasional coverage hole rather than falling back to GSM for a while. I acutally have quite a number of reasons for that:

– HD-voice calls drop to narrow band when the network performs a handover to GSM as there is little support for HD-voice on 2G so far.

– Networks seem to be pretty cautious during voice calls and perform 3G to GSM handovers while there is still sufficient UMTS coverage. During lengthy phone calls this means that Internet connectivity is often needlesly lost, or, in the case of DTM, becomes unbearably slow for most things.

– Most network operators still use GSM A5/1 which is insecure. And even if they use better encryption, lots of organisations are using IMSI catchers and other equipment these days and can easily perform man in the middle attacks. Latest example: The government quarter in Norway.

So unless I'm really in territory which is only covered by GSM (or GSM and LTE), I really want to switch GSM off in my phone. While many 2G/3G devices still had the option to lock the device to 3G, GSM/UMTS/LTE devices usually don't have such an option anymore. Why confuse the user…!? But there's an app for that! Have a look at the "Network" app. It doesn't seem to work on all Android devices but on my Samsung S4 running CyanogenMod it works well indeed. The app is open source so I had a quick look and was surprised that it pretty much just invokes an internal configuration screen that is otherwise hidden.

Which is the best network in a country? There's several ways to answer this questions. A simple answer is that whichever network serves a customer best at a certain location wins at that location. But people are always on the move so in addition to a network serving particular areas individual subscribers are most of their time (i.e. their homes and offices) it is also important to have good coverage along their daily commute routes and also at the places where they spend their vacation, where they go and watch a game, etc. And now the answer to the question has become a lot more difficult. Network tests that published in German news papers are a good indications of how well network cover a country and the 2014 'Connect' magazine test has again undertaken to analyze the mobile networks in Germany, Austria and Switzerland. The report is available in English as a PDF file here and it makes for interesting reading.

Here are some of my findings:

• When comparing this year's results for Germany with those of last year the values have remained pretty much on the same level.

• The other networks in Germany have improved their performance quite significantly compared to last year.

• While the winner in Germany can certainly be proud of its performance, the winners in Austria and Switzerland still surpass it easily. Downlink data transmission rates for a 10 MB file in the Austrian A1 network are on average still significantly higher than in Germany.

• In my blog entry to last year's Connect test I hoped they would also include train tips in their measurements. To my pleasant surprise they have done so and conclude that Switzerland is a travelers dream when it comes to connectivity while especially Germany lacks behind. Time to catch up because I am well aware that the good coverage along the railway line I use a lot is an exception rather than the norm. So network operators in Germany, go have a look how they have done it in Switzerland and do the same!

Until December 2014 I thought that the UMTS air interface was secure. After all, the air interface is much more complex than the GSM air interface and strong authentication and encryption is used. It felt good. And then, a few days before 31C3, news broke that security researches will demonstrate a way to passively intercept SMS messages sent over the UMTS air interface with cheap equipment if the attacker has access to the signaling network used by wireless networks, known as SS7 (Signaling System No. 7), anywhere in the world. And the scenario is only the tip of the iceberg as it turned out only a few days later.

Attacking UMTS Ciphering From The Inside

I never thought about such a scenario before but with the clues given in the article it only took me 5 minutes to figure out the details by having a closer look at the MAP (Mobile Application Part) specification in TS 3GPP TS 29.002. When a subscriber moves from one MSC area to another, the MSCs need to exchange subscriber information and chapter 8.1.4 details the Send Identification service which transfers, among other things, the current ciphering keys from one MSC to another. These ciphering keys can then be used to decrypt transmissions on the UMTS air interface to and from a particular subscriber. The presentation at 31C3 by Karsten Nohl of Security Research Labs a few days later then proved that my assumptions were correct. The slides can be found here and a video of the talk has been posted here.

From a psychological point I found this quick discovery quite interesting. While the message is necessary for proper mobility management in a network and I've known about it from my days as a core network programmer, it never crossed my mind before that this could be exploitable if such messages are routed across network and country borders. But when looking at this from a different angle it becomes immediately obvious. And it seems I was not the only one not to see this because it was reported that all four German cellular networks had no filters in place at network boundaries to prevent such queries. Fortunately, all four reacted quickly and put message filters in place to stop the abuse.

Re-routing Attacks

Unfortunately, the filter just stops this particular exploit. A further talk at 31C3 by Tobias Engel and a presentation by 'Positive Technologies' given earlier in 2014 at a conference in Moscow reveal several other possibilities to exploit the implicit trust between cellular networks to enable roaming between country borders. With access to the global SS7 network anywhere in the world an attacker has several ways to re-route a call to a subscriber somewhere else to record it and then forward it again to the destination. This can be done by sending fake USSD (Unstructured Supplementary Service Data) messages to the HLR (Home Location Register) to activate and deactivate immediate call forwarding. This way an incoming call can automatically be forwarded to a recording station. Once it arrives there the call forwarding is removed and another call is made from the recording station back to the subscriber. Another way described in the presentations linked above is to use the SS7 based CAMEL protocol to change the destination of a call during the establishment process without the need of changing the call forwarding settings in the HLR.

While call re-routing is probably most interesting for spy agencies for political and industrial espionage, researchers have also shown how it is possible redirect SMS messages by sending fake subscriber registration messages across international SS7 links. This way a mobile device is deregistered at its current location and seems to have traveled across international borders. Any incoming calls and SMS messages are thus re-routed to the attacker who can sit anywhere in the world. The subscriber doesn't notice the deregistration as his mobile device continues to show that it is connected to the network. This won't work for long as sooner or later the device will make a periodic location update at its current location or tries to access the Internet and as a consequence the fake registration is deleted. When timed correctly, the temporary redirection can be used for fraud. In combination with banking Trojans that collect banking website login PINs and the knowledge of a user's phone number a confirmation SMS for a transaction triggered by the fraudsters can be redirected into their lap without the user even noticing it. A scary scenario.

Ways To Stop It

The only good news is that these attacks are not passive as they leave traces in the logs of network operators. But that's about it then. In practice it is probably difficult but not impossible to get access to the international SS7 network. For intelligence 'services' around the world it should be no problem whatsoever. So what can be done?

• The first step has already been taken by some network operators by blocking requests for the current ciphering keys from outside their networks.

• Some of the re-routing attacks, e.g. changing call forwarding settings from abroad via USSD can be prevented by plausibility checks, i.e. the HLR or a box in front of it has to verify that the USSD message comes from the Mobile Switching Center to which the subscriber is currently attached to. To prevent spoofing of the sender's SS7 point code, a network operator's international SS7 gateway has to ensure that only messages with international point codes are allowed into the local network.

• Check CAMEL modification messages: The service logic in MSCs must ensure that only Service Control Points (SCPs) from a predefined list of Global Titles can be informed about call establishments and other operations.

• Encryption of national SS7 links: To prevent foreign intelligence services to tap SS7 links in other countries, all SS7 traffic between locations must be encrypted and integrity checked.

• Monitor changing call forwarding settings: Most people don't change their call forwarding settings regularly. I'm probably an exception. A box in the network could watch out for frequent and thus  suspicious call forwarding changes and warn the operator and subscriber.

• Plausibility check international requests for authentication material: Even after barring the exchange of the current ciphering key, networks can still request authentication and ciphering material for subscribers of other networks. This is the basis for international roaming but may also allows those with access to UMTS IMSI catchers to get valid keys. The only way to counter this is to check if an authentication vector request is likely to be valid. If a request comes in from abroad while the mobile just recently made a location update in the home country, it's unlikely that the request was valid. Exceptions are border areas to neighboring countries. That makes plausibility checks not impossible but quite complicated in practice.

• Check international registration requests: The same checks as described in the bullet point above have to be applied to registration requests to prevent enhanced re-routing attacks. As above, preventing such fraud is not impossible but not straight forward to implement in practice.

• Allow subscribers to toggle a "Home Network" lock: If bad comes to worse this would stop any kind of foreign attack if such a lock would block all requests for ciphering material, registrations, etc. etc. from international SS7 links. I'm sure a lot of politicians and high value espionage targets would sleep easier. I'm not sure if this is the same as just deactivating international roaming like it can be done already today… And by the way, such an approach is not novel. Some credit card companies, for example, restrict the use of their cards to countries in which EMV chip/pin authentication is used and require their customers to temporarily unlock their cards if they travel to parts of the world where the magnetic stripe is still used.

• Name, shame and ban: Networks from which illegal SS7 messages are sent should be made public so other network operators can react and also put counter measures in place. If I were a network operator I would also think about terminating my business with that network and blocking all traffic from there. Some examples made public would probably work wonders to convince network operators to keep their back yards clean.

This list is by no means complete and just a result from some initial thinking. I'm sure there is a lot more that can and should be done. Perhaps some of these things are already done by some network operators today but I have no insight into this so I can't say.

So far, nobody has spoken about how to compromise LTE security over international links. This is probably because international LTE roaming is not based on SS7 but on the IP based DIAMETER protocol. The issues are similar however, because the principle is the same: Cellular networks have to trust each other for international roaming to work.

And finally, it's important to understand that none of the SS7 issues discovered by researches and described above require to break any kind of ciphering, to exploit implementation flaws, generate stack overflows to insert malicious code or to apply social engineering to trick someone to do something. Instead they just make use of the protocol in ways it was never intended to be used. In other words, the only way to fix this is to move away from totally trusting external networks and put checks in place that detect and prevent such attacks. Now that things are in the open I guess the industry has some work set out for it to do.

2015 is going to be another interesting year in wireless in Germany as another spectrum auction will perhaps again significantly influence the wireless landscape in the center of Europe.

There's lots of different angles to look at this spectrum auction, including competitive aspects, how much of the spectrum that companies already use today they want to re-acquire, whether it will be a real auction or just an amicable get together now that only three network operators are left, what will be done with the auction result, i.e. reinvested in telecoms, and if so how, or whether the money is funneled into other channels like in the past, etc. etc.

But no, I don't want to look at any of these aspects. Instead, let's have a look at the 2015 spectrum auction from a technology point of view: In addition to re-auctioning spectrum assignments in currently used bands such as the 900 and 1800 MHz bands that expire in 2016, two additional bands will be part of the action as reported by Teltarif and Heise:

Digital Dividend 2 in 700 MHz

The first new band is comprised of 2×30 MHz blocks (one for the uplink and one for the downlink) in the 700 MHz region currently used for TV broadcasting. This part of the spectrum has to be freed up first as part of the "Digital Dividend II" program which foresees terrestrial TV broadcasting to move from DVB-T to the more efficient DVB-T2 standard. The two 30 MHz blocks are between 703 and 733 MHz and from 758 MHz to 788 MHz. That's a subset of the already standardized LTE band 28, which, according to Wikipedia, has been a result of the Asia Pacific Band Plan (APT). In other words it has the same size as the Digital Dividend band (LTE band 20) already used today in the 800 MHz band.

A First in 1400 MHz

The second new band is foreseen for downlink only use between 1452 to 1492 MHz, i.e. 40 MHz. That's a subset of LTE band 32 (1452 to 1496 MHz). As it is uni-directional, it must be used as part of an LTE Carrier Aggregation setup together with another bi-directional band.

And that's it as far as new spectrum is concerned. Making a chunk of uni-directional 40 MHz spectrum available shows how little spectrum there's still available in the area below 3 GHz. Anything above is unlikely to be of much use in a macro cell network setup (i.e. a cell site covering a radius of several hundred meters to a few kilometers).

But every MHz counts and it's going to be interesting to see how things develop in the months to come.

I like to have a plan B so I regularly backup my Owncloud document folder to an external storage device and, in addition, to another Owncloud installation running on a Raspberry Pi so I can active this instance should my main Owncloud installation ever fail while I'm not at home. So far, I've always copied over the complete document folder to the Raspi which takes quite a while as it contains several gigabytes of data. Recently, however, I decided to have a closer look at the rsync command and noticed that it would be ideal to speed up the process as it can compare source and destination and only copies the parts of files that have been modified. Here's the command I put together after reading a couple of "how to's" that exactly fits my needs:

rsync -avzh –rsync-path="sudo rsync" /media/owncloud-drive/data/ pi@192.168.42.3:/media/owncloud-drive/data/ –progress –delete

Looks a bit complicated but it's pretty much straight forward:

• -avzh are the default options to use rsync in "a" = archive mode which goes through the directory recursively and preserves permissions, time stamps and access rights. 'v' stands for verbose output, 'z' for compressing data before transmission, and 'h' for human readable format.

• –rsync-path is used to run the rsync instansce on the remote RaspberryPi with admin rights which are required to copy the owncloud folder that needs to be accessible from the "www-data" account that is used by the web server.

• /media/owncloud-drive/data/ is the path to the local owncloud data folder that is to be copied to the destination.

• pi@192.168.42.3:… is the account, IP address and path of the remote device to which the data shall be copied.

• –progress, as you might imagine gives more details while the command is running.

• –delete allows rsync to delete all files at the destination which no longer exist on the source.

One shouldn't be adventurous when it comes to backups but since this is still in the test phase I ran the rsync command with Apache being shut down on the target but not on the source server. So in theory Owncloud could write to the log or the sqlite database file just at the moment the modified part of the database file is copied over and thus corrupting the destination database file. I've ran the command many times over several days now, and so far I had no issues from not shutting down Owncloud on the source server during the process. Maybe I was just lucky so far or maybe it's no problem at all, I'm not sure yet. But I'll keep you posted.