WirelessMoves

When recently trying out an Android based pad from a major manufacturer I was a bit baffeled that it wouldn't connect in "mass storage" mode to my PC. Instead, the manufacturer wanted me to install a software suite to access the pad's file system. Perhaps this is because the pad has no flash memory slot, just a couple of GB of built in flash. In any case, that was not acceptable at all for me, I don't install software on my PC just to transfer a couple of files. So I started thinking about alternatives and ended up with the Astro File manager and its SMB (Windows file sharing) plug-in to access file systems on Windows and Linux PCs or servers in the network. After sharing the directory that contained the files on the PC and typing in the IP address and the  user name and password of my PC account the file manager on the pad then showed me the files that I could then select and copy over to the local file system over Wi-Fi. Excellent, that's even better than using a cable in the first place!

Near Field Communication (NFC) in mobile devices has been on the agenda for many years now but progress has been very slow. Lately however, there are devices with NFC chips built in comming to the market so I decided it was worth to dig a bit deeper how that works. Getting a single NFC standard accross the industry isn't quite straight forward but some progress has been made in this regard with companies such as Google, Nokia and RIM backing the NFC-Forum based standard for local information exchange and a basis for mobile payment services.

Payment and non-payment (such as receiving a URL from a poster) NFC services rely on the same NFC protocol stack and only differ in how this stack is then made use of by applications on top. I've therefore decided to split up the topic into two posts, with the first describing the basic operation of the NFC protocol stack and how that works with non-payment apps and then in a second post which then describes how NFC can be used for payment purposes.

On the physical layer, NFC uses a carrier frequency of 13.56 MHz to transmit data between two NFC devices via inductive coupling as specified in ISO/IEC 14443. Two transmission modes are specified. The passive mode is used in combination with NFC RFID (Radio Frequency ID) tags that do not have their own power source. In this mode, the originator’s RF field is used as an energy source by the passive RFID tag to return a message. The message is usually short in nature and can for example be an address of a web page (URL) or a business card entry in vCard format.

It is also possible for two active NFC devices to communicate with each other such as two mobile devices or a mobile device and a point of sales (POS) terminal. In active mode, both devices are equal and transmit and send alternatively using their own power source. The practical working distance between two NFC devices is 4 centimeters but much longer ranges can be achieved with high gain antennas. As a consequence, sensitive data exchanges must be encrypted and applications using the communication channel for such information need to authenticate each others to prevent over the air attacks such as eavesdropping, information theft and man-in-the-middle attacks. Supported data rates over the NFC air interface are 106 kbit/s, 202 kbit/s and 424 kbit/s.

The next higher level of the NFC protocol stack defines different message formats. A popular format is the NFC Data Exchange Format (NDEF) defined by the NFC forum. The format defines a general message structure and allows devices to identify what kind of information is contained in the message it has received. The following list gives some examples of message types that can be encoded in an NDEF message:

•    URI (web address, email address)
•    Plain text
•    Smart poster = text + uri
•    Bluetooth and Wi-Fi parameters
•    Business card (vCard format)
•    Signature

Once an NDEF message has been received, a content dispatching system forwards the content of the message to an application that has registered itself for a certain content type. This way, different applications can register themselves for different message types and the dispatching system automatically forwards the message to the application that can handle the particular message type. When several applications register themselves for the same message type a dialogue box is usually presented to the user to choose which application should receive the message. When a web address has been received for example, it could be sent to the web browser while an NDEF message containing a vCard would trigger the address book application that has previously registered itself as a receiver for this kind of content.

Applications on a mobile device can not only receive NFC messages but also transmit them. The address book application for example can be extended to send NFC messages, e.g. an address book entry to the next NFC enabled device that comes in range.

Third party applications can also register themselves as recipients of NDEF messages with a certain content type and can also trigger the transmission of messages themselves. Take Foursquare as an example. The aim of this application is to let users ‘check-in’ at certain locations and share their current location with their friends by various means. The traditional ‘check-in’ procedure uses the GPS receiver in a mobile device to pinpoint the user’s location. The location of the user is then sent to a database in the network to retrieve all places near this location that are registered with Foursquare. The user can then select the place he is visiting. With NFC tags, this process is significantly simplified as the ‘check-in’ is now performed by the user holding his device close to a Foursquare RFID tag. The type of content of the tag is then forwarded to the Foursquare application on the device which then registers the user in the network at the current location. NFC functionality can also be used to exchange information between two Foursquare apps on devices of different users to make friend requests and exchange location lists. This is done by launching the Foursquare applications on both devices and then holding the two devices close together.

So much for now. In part 2, I'll dive a bit into the additions required to use NFC for mobile payment purposes. To come soon…

It's one of those moments in the mobile industry when something happens that is truly a cool first: The first Intel x86 based 'form factor' Android phone is now being sold to end customers as the Xolo X900. For years and years Intel has struggled to put something together that is both fast, power efficient and with the right size. It looks like they've finally made it. Brian Klug over at Anandtech has a full review. He comes to the conclusion that while it's not a leading device yet that blows the rest of the pack out of the water but the performance, size, power consumption and compatability with ARM based Android apps is stunning and competitive. Congrats Intel, after the Wintel marriage broke down with Windows on ARM this shows that it wasn't a one way street!

At some point, hotels with conference capabilities might get it and install a network that doesn't crash when a flock of technophile people arrive and all connect with three devices to the Internet simultaneously via the hotel Wi-Fi. But we aren't quite at that point yet and whenever I am in countries where I can get my hands on SIM cards with enough data allowance (e.g. Germany, Austria, UK)  I offer additional capacity and a stable network to meeting participants (see here, here, here and here for example).

Another possibility is of course to take over the hotel Wi-Fi and fix things yourself, as recently done by a group of IETF engineers before a meeting in Paris at the Hotel Concorde Lafayette. That is of course when things can be fixed in the first place. In many cases it's not only the Wi-Fi but the hotel routers themselves that are overwhelmed by the number of devices suddenly appearing on the network. And if it's not that then it's often the limited uplink capacity that brings everything to a halt. A very interesting story to read, so head over and enjoy.

I am sure you have a backup of the data you have stored stored in the cloud just in case your account gets suspended? No you don't because it's really unlikely? Yes, perhaps, but it recently happend to a friend who uses a couple of Google services to exchange emails and documents and to work on documents together with other people. Imagine the feeling when one day the log-in attempt was greeted with a message like "sorry your account was suspended because you were violating the T&Cs. Your account might be reactivated again, please send an email to us describing your activity". What!?? No serious, that was the message. Fortunately it seems it was only a hickup of the system. When trying to log-in again a couple of minutes later access was restored. Still scary and it shows how much control you have over your data in the cloud…

In a previous post I've been looking at the Nokia 7650 which was released 10 years ago in 2002 and compared it to 2012 devices. Pretty amazing difference. But one can also go back 10 years from the 7650… and land back in 1992, when GSM was first launched. Flagship device of the day: The Siemens P1, have a look here. Now how many orders of magnitude is that?

The point I want to make here: The crazy evolution in mobile did not only happen in the past couple of years since smartphones have become mainstream, it's been happening for a couple of decades now, most people just don't remember anymore.

About a year ago, my Android excursions culminated in me programming my first Android app, which even did something useful for my research on top, a cell logger app that saves cell and location area IDs the app encounters to a text file. Since then I've offered it on the blog for download as an APK file for direct installation and the source code on top for those who want to have a look or play with it themselves. Also, I published it on the Android market (now Google Play) to get a feeling for how complicated it is to publish something there and to see if it would be picked up over time.

And indeed it did. While I don't have any statistics on how often it was downloaded from my blog, Google's market statistics are quite insightful. In one year the app was downloaded to 1357 devices and 300 installs are still active (which doesn't necessarily mean it is used all the time). The numbers might seem quite small, but it's an experimental app so it's probably only useful to few people. So I'm delighted and happy that the app was useful to others as well. Actually to more than I expected. There's still a lot of potential for the app such as adding GPS tracking and maps overlay, etc. Perhaps that's something for after this summer once a current project that consumes my spare time is finished.

You probably still know Windows XP? Of course you do, because it still runs on many computers today, despite having been launched 10 years ago, back in 2002. The look and feel is still the same as back then. But do you remember the Nokia 7650? Probably not because you haven't seen anybody in half a decade using one. But, believe it or not, it was also launched back in 2002 and it was THE high end smartphone of its day to be had for around 600 euros. Let's have a look at the specs then and now:

• CPU: 104 MHz (vs. 1.0 GHz and up today, 1 order of magnitude)
• Storage memory: A whooping 4 MB (vs. 16-32 GB today, almost 4 orders of magnitude)
• Camera: 640×480, i.e. 0.3 Megapixels (vs. 8 megapixels found in most phones today or 41 megapixels of the Nokia 808, 1 order of magnitude)
• Network: GPRS, 40 kbit/s (vs. 21 MBit/s HSPA+, 2 orders of magnitude)
• Display resolution: 176×208 pixels, 4096 colors (vs. 640×960 (iPhone4), not quite an order of magnitude, but you can easily tell..)

And all of this in 10 years. Kind of gives you an idea of what to expect in 10 years from now (apart from Windows XP still running on some machines).

 

So far, I've mostly been looking at Network Address Translation (NAT) as a good counter measure on mobile devices to block unsolicited incoming communication so the modem doesn't have to wake up all the time. Another benefit of NAT is of course also to keep the bad guys away from your devices on the network layer. But actually how much unsolicited traffic is there that reduces battery life in mobile devices and puts your device or local network at risk? As I didn't have any specific numbers on that I decided to try it out to see what happens.

I ran my tests with a Linux PC connected to the Internet and running Wireshark in various ways. In one setup, I used my DSL line. On the router I assigned the Linux PC as a DMZ host, i.e. all unknown incoming packets were forwarded to it. Needless to say that the PC had all current security patches applied and only had the services running that were really require. In another setup I used a 3G dongle and an APN without NAT. The rest of the world didn't really care if the link was fixed or wireless the incoming unsolicited traffic was pretty much the same. Therefore, I don't distinguish between the two in the following.

And here is what happened:

Incoming Traffic Frequency: There was incoming traffic not generated by any of my running applications every 5-10 minutes, i.e. around 10 connection requests per hour, or 10 additional and unnecessary modem wakeup calls.

Type of Incoming Traffic:

Some of the incoming traffic could easily be identified as P2P file sharing connection requests, most likely triggered by a P2P client running on a device that had the IP address I was assigned previously. No harm done here.

Most connection requests had a less harmless nature, definitely sent to see if services are running that could potentially be exploited. Here are some interesting highlights detected during my 6 hour experiment:

• Frequent connection requests to telnet, ssh and http ports. I ran the tests with several different dynamic IP addresses assigned and always got those requests from many different sources. Definitely probes to see if old and outdated services were running that could be exploited.

• Unsolicited SIP requests: I saw those from a number of different originations, so people are running SIP scanners out there to see if VoIP servers are running on systems out there.

• Active VNC attack: I had one instance where the VNC port was probed. As I had a VNC server running on that system the other end started the handshake dialoge and logged off once he had my server version string. I checked with a real VNC client and even when I don't type in the password the communication goes much further than what I saw in this even. There are some VNC server flavours out there that are vulnerable so that was most likely an active attack to scan for those out there.

• Microsofts Remote Desktop Port: I also saw a number of RDP connection requests, so even before the recent criticial security patch for a remote code execution vulnerability, automated scans were running against this port.

• Microsoft SQL database weakness probe

• Unsolicited DNS responses: Every now and then I got DNS response packets which were not triggered by internal DNS queries. The responses contained URLs for xxx sites. I haven't quite understood the background behind that

• Port Scans: General port scans not from P2P services to well known port numbers, e.g. 110 POP3, etc. 

I ran the test with several different IP addresses on different days to ensure I didn't have an IP address that was used by someone else before and thus triggering certain things. The result in each case was the same so all things described above pretty much must be from automated scripts just running up and down the IP address space looking for targets. Also interesting are the countries of origin of those requests. It's pretty much an international phenomenon, requests were coming from everywhere, including the US, European Countries, Russia, China, Australia, etc. etc.

Not a peaceful world out there…

Only a few years ago, the first thing many people did when buying a new 3G phone was to switch to 2G-only mode as they felt it would reduce power consumption. Whether that had an effect or not, that's what they did. Times have changed and today smartphone users leave their device in 2G/3G mode because connected data apps (web browsing, email, instant messaging, etc. etc.) have become an integral part of the experience. I have now gone even further and have switched to 3G-only mode as UMTS coverage has become almost as ubiquitous as 2G in where I live (Cologne-Bonn area). And here's why:

• HD-voice: Quite a number of my friends have HD-voice capable phones now with superior voice quality. For the moment, that's only available on UMTS in practice so I don't want my phone to be handed over to 2G and thus be kicked back to the traditional narrow-band voice codec.

• Simultaneous voice and data: Especially during longer conference calls I take on the mobile phone I like to be able to switch to the web browser or the email client to do some background research. UMTS had the simultaneous voice and data connectivity already back in day 1 and I've become used to it and don't want to be thrown to 2G during the voice call and my data applications to stop working. 

• Security: Yes, this one's perhaps a bit on the paranoid side but GSM is not as uncrackable anymore as it used to be. Better to be on the 3G side.

Admittedly, I switch back to dual-mode 2G/3G when I travel as 3G coverage is not as ubiquitous as in my home town.