SweynTooth BLE: 4 Things You Need to Do

By: Bill O’Brien – Senior Manager, Customer Projects – MMB Networks

TL:DR; A massive BLE security vulnerability was found in microprocessor SDKs. Microprocessor and device manufacturers are all over it. Your product roadmap is NOT in jeopardy, and we walk through the importance of staying up to date on standards and the other commitments you need to make when getting into the IoT.

It’s been a few weeks since the industry was notified about the discovery of security vulnerabilities within Bluetooth LE devices. We thought it might be helpful to point out what we think you should be doing to ensure you, your products, and your customers come out of this with minimal disruption.

  1. Don’t panic

    You can still safely develop with BLE. Exploiting these vulnerabilities is hard for would-be attackers, and a patch to fix the vulnerabilities for most affected devices has already been released by most microprocessor manufacturers.

  2. Update your devices

    With your microprocessor manufacturer’s guidance, you will likely have to update your SDK, recompile your device software in the new environment, and release an update to your customers.

  3. Review the latest Protocol standards and Certification tests

    The next thing to think about is that this is a stark reminder for IoT device manufacturers to stay current on the latest developments in protocol standards and the accompanying Certification tests. And to ensure that those tests adequately push the boundaries of hardware/software.

  4. Think long term when it comes to support

    Finally, for those that may be thinking of getting into the world of IoT, be prepared to commit to a long relationship with IoT devices that you deploy into the field.

Keep reading to learn more about what happened and what you can do about it.

What happened?

Recently published research from a team of researchers from the Singapore University of Technology and Design has been making the rounds in the tech community this past week. Their research uncovered a critical security vulnerability with Bluetooth Low Energy (BLE) devices. This vulnerability, dubbed Sweyntooth, impacts millions of consumer end-devices that have already been deployed in the market for some time.

What is BLE?

Just in case there are a few readers that may not know, Bluetooth Low Energy is a wireless communication standard designed specifically for low power applications, usually found in wearables or smart home devices.

Compared to the more widely known full version of Bluetooth we all have in our phones, BLE devices communicate over much shorter distances, and transmit data at a slower rate.

As a result, this connectivity standard requires less power to function properly, so it can then be used in small devices (with very small batteries) that are expected to operate for a day or more without recharging or having the batteries replaced.

What vulnerabilities did they find?

The researchers identified a family of 12 different vulnerabilities in the BLE software implementation currently used by a number of microprocessor manufacturer’s software development kits (SDKs) that are found in millions of currently deployed devices.

An SDK compiles the device manufacturer’s application that runs on the microprocessor in the device. This means that the flaws found by the research team have been inadvertently baked directly into the application code.

These vulnerabilities would allow an attacker within radio range of the device (less than 100m), to cause the device to crash or completely bypass security. This could then potentially allow would-be attackers to gain full control of the device.

The bad news is that because the vulnerabilities are found within the SDK for the microprocessor in the device, and these microprocessors are used by many different end-user device manufacturers – vulnerabilities found in a microprocessor can spread across many different end-user device categories.

It’s also good news that the problem is caused by the SDK. Each manufacturer can fix the problem in their devices by updating their SDK to eliminate the flaw(s), then re-compile and release the updated software to the devices.

This discovery of security vulnerabilities within BLE was taken seriously by major players in the industry. Before the announcement was even made public, many of the microprocessor manufacturers updated their SDKs. This was closely followed by a number of device manufacturers, who then quickly updated their products with the necessary patches to remove the vulnerabilities.

No physical changes to the device, in the form of recalls, should be necessary.

How were the vulnerabilities missed in the first place?

Just like devices leveraging other technologies like WiFi or Thread, Bluetooth devices must undergo a rigorous certification process. This process includes some security testing. Unfortunately, in this case it looks as though these vulnerabilities were missed by the standard certification test.

It will be up to the Bluetooth Special Interests Group (Bluetooth SiG), the standard-setting body for all Bluetooth protocols including BLE, to update and reinforce the security tests in the certification tests to reflect these new vulnerabilities.

Manufacturers of both end-devices and microprocessors, plus the standards groups who define the communications protocols used to deploy various applications, need to get creative when it comes to testing. They can’t afford to be complacent and conclude that because a product is “simple” that security isn’t as critical (see: Connected coffee makers that can be hacked).

More generally, ensuring the security of IoT devices is becoming more important as more of these kinds of vulnerabilities are discovered. Designing secure devices and keeping them secure is critical for the IoT industry as smart devices become more entwined in our daily lives.

Is my product roadmap compromised? If so, what do I do?

These vulnerabilities cannot be exploited remotely over the internet – an attacker must be within radio range of the device (100 meters or less). This reduces, but doesn’t eliminate your device’s vulnerability to attack.

Of the devices impacted by this vulnerability, particularly concerning are security (eg. door locks) and medical devices (eg. pacemakers).

It’s not such a big deal if a consumer’s activity monitor crashes or its data is compromised, but it’s another story if their front door can be unlocked without a code. And nobody wants their pacemaker to stop working or start delivering a dangerous rhythm.

Some good news is that if you’re an end-device manufacturer with a product already moving through your development cycle, you can check to see which specific microprocessors are affected here. You can then ensure the SDK you’re using is up-to-date and continue on with development.

If you already have devices in the wild that use one of the affected microprocessors, Don’t Panic! Contact your microprocessor manufacturer for their guidance on how to address the issue.

Of the seven microprocessor manufacturers the researchers alerted to these findings, four have already publicly released patches to fix the vulnerabilities: Texas Instruments, NXP, Cypress, and Telink Semiconductor.

From an industry-wide perspective, because the vulnerability is specific to the microprocessor in the end-device, it isn’t easy to identify every end-device in the field that’s been impacted. You can find a partial list of those products here.

If you own one of these end-devices, you should update the software on the device(s) as soon as possible. It should be noted that some manufacturers are still working on releasing a fix for their devices so new software may not be immediately available. If this is the case, keep a close eye out for new updates/releases.

Now what? Do we avoid developing BLE solutions altogether?

In practical terms, there’s no need to change your immediate technology strategy. As already mentioned, these vulnerabilities are challenging to exploit in the field.

Not only that, BLE is a well recognized standard with significant support from industry groups and BLE is certainly not unique in having security vulnerabilities found within it (see recent security issues involving other wireless protocols – Ring cameras, Hue lightbulbs).

What should I do going forward?

Consumer device manufacturers need to stay on top of the latest releases coming from the standards groups supporting the protocols they’ve selected for their products. This ensures they can react quickly when issues like this latest BLE vulnerability are identified, or base requirements change.

As connected devices have become more prolific and cyber security becomes critical to national security, governments have begun to legislate and/or set standards for such products. In fact, the UK government is already far along this path.

Finally, device security is an ongoing commitment that will continue for the entire life of your product. If you’re developing an IoT end-device, best practices dictate you should include planning for ongoing support long after you’ve stopped selling the product. Microsoft continued to offer security patches for Windows 98 for almost 20 years after they stopped selling it (and even after they released three new versions of Windows during that time frame).

This research should serve as a reminder for the IoT industry that device security cannot be taken for granted. Testing device operation within the engineering specifications, as has been common industry practice, is not sufficient. We need to dream up crazy use cases and always try to break our devices – we will rarely be disappointed by our efforts.

Get The Inside Track

Fill out the form below to sign-up for news, insights, and more.