Design_World_-_Internet_of_Things_Handbook_April_2020

32 DESIGN WORLD — EE NETWORK 4 • 2020 eeworldonline.com | designworldonline.com

INTERNET OF THINGS HANDBOOK

to sniff BLE signals up to 1 km away, though
BLE signals typically travel only up to 100 m.
To prove their point, the OSU researchers built
their own BLE sniffi ng device using not much
more than a Raspberry Pi and a BLE antenna.
This DIY sniffer identifi ed 431 vulnerable
devices, including 369 units where the
researchers could eavesdrop on conversations,
within an area of just 1.28 square-miles.
Work by the OSU researchers shows what
steps attackers must take when trying to decipher
UUIDs. Sometimes UUIDs are directly hardcoded
in the app. In this case, they may be extracted
simply by looking for regular strings of characters
(grepping) in the decompiled app code.
UUIDs associated with an IoT device also
typically have a hierarchical structure. A service
UUID can have “children” UUIDs derived from
its characteristics. Such a UUID hierarchy could
provide information useful for determining
which IoT app maps to a particular BLE device.
One complicating factor is that no structural
rules defi ne relationships between parent and
children UUIDs, so some educated guessing
may be involved.
OSU researchers also explain the general
approach attackers would likely take in fi guring
out whether an app itself is insecure. The only
way a nearby attacker can sniff vulnerable
IoT devices paired via Just Works is to fi gure
out whether the app involved uses fl awed or
insecure authentication. To implement proper
authentication, the app must use cryptography
to prevent a relay attack either by encrypting
the authentication token with nounces
(arbitrary numbers used only once to ensure
communications can’t be reused) or by using
an additional layer of encryption of the traffi c
atop BLE link-layer encryption. Thus to check

the app for security, the approach is to look

at the disassembled app code for any use of

cryptography. If there’s no cryptography, the

conclusion is the channel is not secure, and

both passive/active sniffi ng and unauthorized

access can be successful.

Even in apps employing cryptography,

fl awed authentication can rear its ugly

head. One such fl aw is the hardcoding of all

credentials in the app, potentially discernible

by disassembling the code. However, OSU

researchers say it can be challenging to

identify authentication fl aws because there

is no specifi c code pattern for implementing

app authentication. Thus there’s no

documented APIs to identify for extraction of

the hardcoded credentials.

It turns out that fl awed authentication

involving hardcoded credentials can be

identifi ed systematically. The key insight is that

to securely authenticate a mobile app to a BLE

device, the app must provide a credential that

comes from the external input, such as letting

the user enter a password. OSU researchers

say this opens up the possibility of using a

data fl ow analysis algorithm to identify such

apps. This approach, if used for nefarious

purposes, implies an extremely determined

attacker: The technique would likely involve

creating data-fl ow equations for each node of

the app’s control fl ow graph and solving them

by repeatedly calculating the output from the

input locally at each node.

In particular, researchers say data sent out

to BLE peripheral must go through low-level

APIs, allowing use of program slicing-basically

looking at a subset of program statements that

affect a variable of interest--to trace back to the

source of the data. If none of the data sources

are external inputs (e.g., received from the

BLE network or user inputs), then the app has

used hardcoded commands including possible

passwords to interact with the BLE devices

Researchers also note that further

intelligence may be gained by knowing

where the UUIDs are used (i.e., the execution

context). There are seven documented APIs

defi ned by the Android BLE framework that

carry the UUIDs as parameters, to generate

the instances for accessing the related service,

characteristic and descriptor in the paired BLE

devices. While an app could have multiple

UUIDs, their usage may have dependencies

that can be exploited.

COUNTERMEASURES

To head off vulnerabilities, researchers say

the app should encrypt the data sent with

no hard-coding of any factors involved in the

encryption. Developers should also hide the

authentication credentials in the cloud or let

users enter them in the app.

The root vulnerability that enables

UUID fi ngerprinting is that BLE devices must

broadcast advertised packets to inform nearby

apps. The UUID can be sniffed either from

the advertisement packets or by browsing for

services after the connection has happened.

In addition, UUIDs are fi xed values and do not

change over time.

The fi ngerprinting attack relies on mobile

app analysis to reveal the UUIDs and their

hierarchies, So anything that discourages this

sort of analysis can be helpful.

Researchers also say that although

protection methods in the app-level are

seemingly plausible, they can’t fundamentally

prevent the UUIDs from being reverse

Application / profiles

Audio Control

Baseband

Link manager

Physical radio

Other LLC RF comm Telephony

Service

discovery

Logical link adaptation protocol

Application

layer

Middleware

layer

Data link

layer

Physical

layer

Bluetooth protocol stack

The protocol stack for

Bluetooth. Security

problems arise when

security measures are

implemented at the app

level but in ways that

can be discerned by

examining the app code.

• Maximum height of 0.45 mm ... 30% lower than competition


• 23 inductance values available ... from 1.2 to 56 nH


• Excellent Q Factors ... up to 84 at 2.4 GHz


• Very high SRF ... as high as 27.5 GHz

Full Specs & Free Samples @ coilcraft.com

0402CT Series

Low-profile Ceramic Chip Inductors