Categories

Last year the Edinburgh branch of the British Computing Society (BCS) invited me to give the Sidney Michaelson Memorial Lecture at the 2017 edition of the Edinburgh International Science Festival (EIFS). I felt honoured, as Sidney was the first professor to be appointment by the Computer Science department at the University Edinburgh. I was also grateful to be given the freedom to pick the topic of my talk, since at the time I was embarking on a new research adventure with fabulous people. Together with Matthias Hollick‘s team at TU Darmstadt, we were gaining interesting insights into the operation and flaws of wearables. I was also visiting Guevara Noubir at Northeastern University in Boston and was beginning to investigate the privacy risks posed by wearable devices. Such issued were resonating with increasingly more people, triggered perhaps in part by the revelations uncovered by Edward Snowden. I should also thank my partner for encouraging me to speak publicly about the discoveries I was making.

The overall experience of talking at the EIFS in April is well worth remembering. My hosts Prof. Bill Buchanan, Margus Lind (now my postgraduate student!), and the entire festival team were very kind, and the audience asked excellent questions that led to interesting discussions. They also inspired me to continue my work. In preparation of my talk, partially in airports and on flights, I scribbled some notes to make sure I would not ramble. In a nutshell I wanted to give the audience a good taste of what is currently possible to achieve in terms of surveillance with inexpensive hardware, but also what steps can be taken to preserve user privacy. I later thought I should not discard these notes and turn them into the blog post you are reading now. This should have seen the light months ago, but as the year is coming to an end, it’s not time to fret. So let’s get started.

Why this is a good time to discuss wearables privacy

Internet connected wearable devices have gained massive popularity over the recent years. This is because their cost continues to drop and users increasingly rely on them to improve the quality and efficiency of their daily lives. For instance a smart watch can be used today to answer calls or even pay for coffee. The gadget is effectively a small computer, that beyond time keeping functionality, has a touch screen and a set of sensors, runs a miniature operating system, and hosts applications ranging from text messaging tools, to calendars and music players.

The concept is not exactly new! 40+ years ago the first calculator watches with LED displays were launched to market by Pulsar, albeit for $4,000 per unit. They were obviously not Internet connected, since at the time the research community was only beginning work on packet switching and wireless data communication was merely limited to DARPA experiments in the San Francisco Bay area. Fast forward to present days, we now call wearable technology any electronic device that measures some parameter(s) and/or provides a limited function. These device may be worn as accessories or could be implanted in the body, while being in some way connected to the Internet. By far the most popular wearables today are wristbands that track user’s physical activity and sleep habits. Analysts estimate hundreds of millions of such devices will be sold by 2020 and in the long run there is hope they could help healthcare professionals make early diagnosis or monitor patients diagnosed with certain conditions.

Smart contact lens a the one pictured above are also under development, which aim to monitor blood glucose levels in patients who suffer from diabetes. The key feature is non-intrusiveness, as these lenses will be continuously measuring the chemical contents of a user’s tears and notify them via a smart phone app when they should take their insulin dosage (or even trigger a wireless insulin pump as needed!).

This is exciting, yet the media frequently reports major security vulnerabilities discovered in wearable devices, which raises legitimate concerns about their trustworthiness and privacy. For instance researchers demonstrated that the microphone and accelerometer of smart watches can be used to infer ATM PIN numbers. We also showed recently that the protocol governing the communication between fitness trackers and the cloud, can be compromised to leak private information.

It is thus only natural to ask what the root causes of privacy risks are and why we only ask these questions now. There are several reasons:

First, these devices have rather limited computational capabilities, therefore implementing robust security mechanisms is hard. The user interface is also minimal, often consisting only of a simple button or a tiny display.

Second, the system designs are negligent (or often beyond the vendor’s control once steps of the production process are outsourced) and in the rush to be first on the market, security remains an afterthought.

Third, there is currently a shortage of developers who have intimate understanding of both embedded systems, wireless networking, and security.

I argue now is the right time to discuss privacy, since tens of million such gadgets are sold yearly, and their potential and societal impact can only be fulfilled if users not only recognise their utility, but also feel confident that they cannot be exploited for malicious purposes.

On wireless channels, anyone can hear you scream

Let us dive into some technical aspects, in order to better understand where privacy risks are rooted. The picture below summarises the typical end-to-end communication paradigm between wearables and the vendor’s application server.

Gadgets that collect measurements periodically send these over Bluetooth or Wi-Fi to the user’s smartphone or tablet. The mobile device then encapsulates activity reports into network packets and forwards these to a server over the Internet. Most frequently this is done via a wireless access network at home or at work. The server computes and stores statistics associated with individual user accounts, and sends back summaries to be displayed onto dashboards within apps that run on mobile devices.

The communication channel between the wearable device and the user’s phone or tablet is wireless and inherently broadcast. Therefore risks of eavesdropping and intercepting sensitive information exist. It also remains questionable what the mobile app does with the data collected by wearable devices. A malicious individual could further perform man-in-the-middle (MITM) attacks and intercept user data as it leaves the wireless access point. Nonetheless, if the server does not implement rigorous security, an attacker could impersonate a victim and retrieve information kept with their account.

Private information leaks aside, there are also risks of surveillance if an individual can be linked to a wireless device. In particular Wi-Fi devices periodically send broadcast probe requests to discover wireless APs within range. The unique hardware address identifying the sender is present in such probe packets. The address of a device is visible in clear also in data packets whose payload is encrypted. This brings the risk of identifying individual users and potentially social relations among them.

Things are slightly different when Bluetooth or Bluetooth Low Energy (BLE) is employed for communication. In particular, Bluetooth devices do not transmit on a single channel (frequency) as is the case with Wi-Fi. Instead, a communicating pair continuously hops on different channels according to a pseudo-random sequence upon which they agree beforehand. This makes packet sniffing considerable more challenging and one may tend to believe surveillance risk less critical as well. The majority of devices are however ‘discoverable’, which means they will respond to so called ‘inquiry’ messages, by which they reveal their hardware address. Some may become un-discoverable after the pairing process, though it may still be possible to intercept packets if changing channels intelligently or listening on multiple channels simultaneously, yet this remains an open research problem.

BLE was first marketed as ‘Bluetooth Smart’, which from a privacy perspective was misleading. This is because BLE employs dedicated channels on which devices periodically advertise their presence. Thus users may be susceptible to surveillance once again through the unique addresses of their devices.

With the right tools you can do (almost) anything

Of course one may ask how difficult it is to perform any of these attacks, whether expensive tools are required, or if compromising user privacy involves having solid expertise. Regrettably, such attacks are feasible with affordable open-source hardware and free software tools, particularly those developed for the Linux OS. This includes tools available with the official Linux Bluetooth stack, such as bluetoothctl and hcitool, or the Ubertooth suite that can sniff data packets exchanged by BT/BLE devices within range, then extract part of their addresses.

Importantly, when the user’s smartphone is not in range, switched off, or simply in flight mode, wearable devices become easily discoverable. I put the open-source tools to work in such a scenario while on my way to Milan in March. Within less than one minute I was able to discover 13 devices, 4 of them clearly smart wristbands.

Bluetooth/BLE device discovered within seconds in flight from Edinburgh to Milan. Four of these are clearly fitness trackers.

MITM attacks take more effort to mount. However, once the user accepts the certificate pushed by a rogue Wi-Fi router when connecting, information transmitted over HTTPS and thus presumably secured can be intercepted. If the victim initiates account pairing, the attacker can obtain information about the user’s mobile device type, the email address and password associated with the account, and potentially sensitive personal details such the user’s weight and body mass index (BMI).

User email, password, weight, BMI details obtained via MITM attack.

If the victim synchronises the tracker with the server, for the case of devices that do not encrypt the payload end-to-end, we were able to personal details including distance travelled, calories consumed, and for how long the user has been active.

Lessons to be learned

By experimenting with open-source tools and reverse-engineering the operation of fitness trackers, we have been learning several important things.

Firstly, as long as devices continue to work with uniquely identifiable hardware addresses, users will be traceable as well. You may even imagine a crowdsourced service by which the location of an individual could be tracked if the address corresponding to one of their wearable devices is known. This is frequently encountered on the packaging of the device. The good news is that recent Bluetooth amendments enable manufacturers to periodically change the address of a device in order to improve privacy. This is not a mandatory feature, therefore at the moment only seldomly implemented. Address randomization is supported for Wi-Fi technology with Windows 10, Max OS X 8, and Android 6, while changing a NIC’s address has always been easy in Linux. There may circumstances where address randomisation is impractical, e.g. in corporate environments where the administrator expect devices to be always identifiable with the same addresses. The not so good news is that device fingerprinting by signatures built upon the distinct features of the radio signal these emit proves address randomisation may soon be insufficient.

Secondly, users should understand if connecting to a ‘free’ Wi-Fi hot-spot does not entail MITM risks. Nonetheless, users should always change the default passwords on the devices they manage, otherwise this is the perfect way to have your device recruited in a botnet (see Mirai).

Thirdly, dance like nobody’s watching, encrypt like everyone is. There is so much encryption one can implement without modifying device firmware, yet if connecting through Wi-Fi networks that you do not necessarily trust, set up a Virtual Private Network (VPN) first. If you plan to buy a wearable device, do some research first and understand which one might be more secure.

Privacy can improve only if everyone cares

It is only fair to ask in the end:

once privacy or security issues have been identified, who is responsible for patching the software and remedying these?

The manufacturers have in depth knowledge of the hardware and software
and for sure they should be the ones driving the effort of fixing security problems. However, more investment in training developers is needed and the code they produce should be rigorously verified. Large retailers could also prevent the release of devices with serious flaws, if performing penetration testing and working with the vendors well ahead of distribution. Nonetheless, if new software/firmware upgrades are being made available, the device owners should be performing the updates. The manufacturers have the duty of ensuring the update process does not appear complicated to users with limited technology knowledge and they should understand users often lack patience. But what what if a vendor goes into liquidation (as in the recent example with Jawbone) and thus patching vulnerabilities becomes impossible? That scenario is no longer hypothetical and something on which regulators together with vendors and researchers should work, so as to be avoided.

I am frequently contacted by students interested in doing a PhD, therefore I thought it may be worth clarifying a few things. This should help potential candidates prepare a good application, while understanding why some never receive a reply –it’s likely not #3 as in the PhDcomics cartoon below.

If you came across a PhD opening under my supervision through various websites, mailing lists, or adverts posted by the University of Edinburgh on social media, this means there is some funding available in the School of Informatics and a rigorous selection process has been put in place. Read the adverts carefully, check the eligibility criteria, and prepare a CV and a clear research proposal. You should be able to learn a little about my research through my website, but I also need to understand your background, your research interests, and how you plan to pursue these, in order to be able to work together. Therefore, you should send:

An up-to-date CV;

A research proposal;

Copies of your academic transcripts;

The names and contact details of two referees.

If you are unable to provide the above information, I will not respond to your email. The same holds if you have your own funding, but do not send me these details.

Likewise, if you plan to pursue a PhD in an area that is only marginally related to my research or you are applying to multiple universities, but did not take the time to write a brief enquiry email that is addressed to me instead of someone else, you will not receive a response. I cannot supervise on topics on which I have limited expertise, while if you aspire to study at an university that is not Edinburgh, you should apply there.

We do not offer feedback to unsuccessful candidates who have not been invited for an interview. However, you will receive a notification email to let you know of the outcome of the first stage screening.

You should avoid the following things, which certainly will not help you build a stronger case:

Do not send reference letters. We will contact your referees as appropriate;

Do not send copies of your MSc thesis or publications you co-authored, unless we have explicitly asked for such documents;

Do not send me an excessive number of emails if you did not receive a response. Make sure there is an opening (or you have your own funding) and you fulfil the eligibility criteria.

If it turns out you are the best candidate for the post, it is very likely that you will receive an offer. I appreciate if you respond to offers promptly, to ensure other candidates can benefit from the available funding, should you change your mind.

Growing increasingly concerned with Google’s intrusiveness and slack privacy policy, I saluted Ubuntu’s efforts to move into the mobile OS landscape. Do not get me wrong, I enjoy the quality of the Google products and Android for that matter, but hoped for a tighter control of my data and at the same time wanted to encourage competition. After all, this is what drives innovation. Thus I found the Ubuntu Edge crowdfunding campaign to be a promising step towards developing an alternative to Android/iOS/Windows phones, albeit rather ambitious. The project was not funded, but Canonical did not give up and partnered with the Spanish company BQ to release Aquaris E4.5 as the first Ubuntu Phone in January 2015. The device was affordable, though the specifications were somewhat modest (e.g. lack of LTE modem) and I decided to wait for a next release.

Meizu MX4 Ubuntu Edition was announced in July and this seemed the right time to try an Ubuntu phone. One had to play an origami game for a chance to win an invitation to buy a device, with only three tries per day allowed. The verification was cookie based and private browsing enabled me to play the game for several minutes, until I could order the phone. It finally arrived a few days ago and I was quite excited.

Ubuntu Touch overview

I will not discuss Meizu MX4 (GSM arena provide detailed specifications), though I will only say I dislike the glossy back cover, which makes the phone feel slippery in hand, and the fact that it was shipped with marketing material for Flyme 4 OS. The focus of the discussion hereafter is on Ubuntu Touch’s functionality.

The device is running a modified Ubuntu 15.04 (r3 after the first update) whose UX is based on Unity 8. The OS boots super fast, which would be advantageous when recharging a depleted battery. You may want to avoid that though, since the phone only boots after a couple of minutes when the battery drained and was subsequently plugged to the mains. It is also worth mentioning that one of the claimed advantages is extended battery life, but after a couple of days with minimal usage I have to say the LG Nexus was scoring more points here.

Interacting with the phone is all about different types of swipes in terms of direction and length, but that gets complicated at times.

Scopes

The user interface is based around ‘Scopes’, which are merely widgets that do not replace apps and do not improve usability. Navigation is based on Here and that is nice, as it provides a decent alternative to Google maps. The major problem is localisation, since the engine fails to identify the (rough) position of the user when indoors. For instance, Meizu MX4 will often locate me in London and offer ‘Nearby’ recommendations for that instead of Edinburgh (to which a Scotsman would raise an eyebrow).

There is a scope that checks the user’s FitBit activity (if you own such a tracker), though that does not interface directly with the bracelet, but instead queries what has been recorded already into a web account. Naturally, this forces one to synch the FitBit bracelet with a desktop, which questions the use of a smart phone.

Apps

In terms of apps, as one may expect, there aren’t that many to talk about and the few essential ones (phone, SMS, email) still require some work. For instance, writing a new text message without having to first browse through contacts seems impossible, while the screen is locked during an ongoing call. The phone app is hidden upon unlocking, which leaves the call active for longer than required and this is rather inconvenient. Rebooting was also required during testing, to make sure notifications about incoming calls were triggered. Regarding notifications, these do not disappear if the events have been cleared on a different device (e.g. when reading email on a desktop).

Email, Twitter, YouTube, etc. are merely HTML wrappers that work with the mobile version of the respective web sites and have to be restarted frequently. The Ubuntu browser seems fast though. Listening to music on YouTube is paused when locking the screen, which is very inconvenient if the phone is inside a pocket, where one may accidentally press some controls. The audio quality is not great either, but whether that is a device or OS issue remains debatable.

The calendar app is rather modest and it will not fetch shared Calendars from a Google account. There are apps that work more or less with Dropbox, Airbnb, Skyscanner, and YR.no services. On the other hand, there is no support for Vivino, Last.fm, and Edinburgh Bus (should you care about these), while services such as Tripadvisor, Tripit or Spotify seem not to have been thoroughly tested. At this stage, I do not expect Internet banking apps to be trustworthy.

In Summary

For someone relying on the smart phone for work, email, calendar, SMS, and call apps should work flawlessly and unfortunately that is not the case with Ubuntu Phone at the moment. I am glad I bought the device, but it reminds me of the early days of Linux, when most people I knew were using a Windows machine and the Linux distributions were not keeping up with the competition. However, I trust the open source community will continue working on improving the OS and develop new applications, which would make Ubuntu a true contender in the smart phone market.