C

Consiglio Nazionale delle Ricerche

An example of smartphone Bluetooth Low Energy access control system

A. Mancini

IIT TR-06/2016

Technical Report

Aprile 2016

Iit

Istituto di Informatica e Telematica

An example of smartphone Bluetooth Low Energy access control system

Alessandro Mancini

IIT Institute, National Research Council of Italy via G. Moruzzi, 1 – 56124 Pisa, Italy

email: {firstname.lastname}@iit.cnr.it

Abstract. The massive diffusion of smartphone, tablets and the upcoming arrival of new wearable devices are fueling the need to find intelligent solutions to everyday problems, by simplifying and improving the use of things we are already accustomed to.

Thanks to the processing power, wireless communication and networking available on our mobile devices, adopted by a growing number of people, it is possible to deliver advanced services to a multitude of users, even if they are not particularly experts in the IT field. This allows us to develop new paradigms of interaction human-to-objects.

In this document it is described a prototype system, that employs technologies designed for mobile devices, to realize an access control system. Being well aware that commercial solutions already exist, the intent is to explore and demonstrate new features provided by the devices that we use daily.

Keywords: Bluetooth Low Energy, iBeacon, smartphone, IoT.

ii

Table of contents 1. Introduction ............................................................................................................... 1

2. iBeacon technology ................................................................................................... 12.1. Micro-location ................................................................................................................. 22.2. Interaction, Engagement, Context ................................................................................... 22.3. iBeacon IDs and location regions ................................................................................... 22.4. Security ........................................................................................................................... 3

3. Prototype .................................................................................................................... 33.1. Architecture ..................................................................................................................... 33.2. The checkpoint device .................................................................................................... 43.3. Transmitting an iBeacon ................................................................................................. 53.4. Controlling relay module ................................................................................................ 6

4. System operation ....................................................................................................... 7

5. Conclusions ............................................................................................................... 8

References ........................................................................................................................ 9

1

1. INTRODUCTION

In this document we describe a prototype of a control system and electronic access by smartphone. We are going to control an opening system using a low-cost hardware; this is a way to achieve a sort of software-controlled electronic lock.

We want to control the opening of a lock by using a smartphone or a tablet. Managing transactions electronically, we can keep track (by a log file or a more complex system) of which users have made requests for “door opening”.

Solutions for physical access control already exist in the market. These often require the use of electronic badges or smart cards, which, as the same for a keychain, may be lost or (voluntary) exchanged or lent. Other systems rely on fingerprint recognition; in this case digital dermatoglyphics of all authorized users are stored into the access control system, and this may raise some concern about privacy and the use of biometric data.

Nowadays, the smartphone has become a very personal device that people always brings with, so we can consider it the ideal candidate for an identification system. People prefer to use their own device, in fact, the BYOD1 policy is more and more accepted at work. In this way the authorization system has a client on which run the companion app without having to purchase any additional components. Furthermore, we are witnessing adoption of several wearable devices, like smart-watches, according to a survey by Gartner (Garther, 2014), by 2017 30% of wearable devices will be discreet and completely “invisible” to the eyes.

In this technical report we analyse some technologies introduced by Apple Inc. (a major manufacturer of smartphone and other portable devices worldwide) in the last few years, that allows users to interact in close proximity to other equipment. These technologies have also been ported in all recent Android devices. Finally we describe how low-cost and general-purpose hardware can be used to achieve an access control system.

2. IBEACON TECHNOLOGY

Apple introduced iBeacon in 2013, this name refers to a particular technology that allows an app running on a enabled Apple device, to know if is in the proximity of a wireless transmitter called iBeacon emitter (or simply “iBeacon”). Despite the name, all recent Android devices already support it too, Google released a Bluetooth Low Energy beacon profile in July 2015, called Eddystone (Google, Inc., 2016).

iBeacon relies on Bluetooth 4.0 Low Energy (BLE) standard. It allows precise indoor geo-location and contextual interaction or engagement as well; when the mobile device is in range of an iBeacon, it can trigger some specific functionality.

1 Bring your own device (BYOD) – refers to the policy of permitting employees to bring personally owned mobile devices to their workplace, and to use those devices to access privileged company information and applications.

2

2.1. Micro-location

iBeacons technology allows your mobile app to understand its position, even in indoor where is not possible to catch GPS satellite, this kind of geo-location with high level of granularity is called micro-location.

An iBeacon-enabled app is notified where the mobile terminal is in range of iBeacons, and it is able to detect the distance when proximity changes. In this way the app knows precisely where is located, not by longitude/latitude (the GPS way), but considering the distance of the mobile relative to known points.

iBeacons emitters are small battery-operated radios, when mobile device gets in range, it senses the signal and locates itself.

Fig. 1: Section of a Beacon produced by Estimote, Inc.

iBeacons broadcast a message periodically (the interval is measurable in some hundreds of ms) to any device within the range of the BLE signal, each iBeacon has its own ID, so the mobile device is able to recognize the context of its surroundings. No data payload is transmitted by iBeacon, only a customizable identification.

If iBeacons are located strategically, the smartphone or tablet is able to determine its position with extreme precision, accuracy far higher than that of GPS.

2.2. Interaction, Engagement, Context

An iBeacon-enabled mobile app can react to iBeacon signals. Example: some functionality to perform a specific action on a specific mobile device, in an precise time of a certain location…

In simple terms: “this is where you are” and “this is what you (can) do”. So, iBeacon can be used to engage with people in a physical environment through their mobile/wearable devices.

2.3. iBeacon IDs and location regions

An iBeacon is identified by three customizable values: Proximity UUID (128 bit), major (16 bit) and minor (16 bit) values. This split allows to have three levels of micro-location

3

identification: Proximity UUID only, Proximity UUID + major value, Proximity UUID + major + minor value.

In addition, the iBeacon signal allow to estimate the distance from the source quite accurately, three ranges are defined:

• Far (low signal, 2.5 meters or more)

• Near (between 50 cm and 2/5 meters)

• Immediate (less that 50 cm)

So, it is possible to restrict the recognition of an iBeacon also based on the distance/region.

2.4. Security

The iBeacon transmitter sends a public plainly visible frame, anyone in proximity can receive it and there are no encryption or security mechanisms. Anyone can take the ID and use it with an unofficial app, and anyone can capture, copy and reproduce the iBeacon advertisement frames at different physical locations.

This is not a security flaw in the iBeacon per se, but application developers must keep this aspect in mind when designing their applications with iBeacons.

3. PROTOTYPE

3.1. Architecture

The architecture is composed by three main elements:

• A checkpoint device, a prototype hardware which acts as iBeacon emitter and a relay controller

• A mobile app, which interact with the system

• Access controller: a main server which coordinates the communications between the components

Fig. 2: System architecture

4

3.2. The checkpoint device

The prototype described in this document is based on a cheap single-board computer Raspberry Pi model B+, this hardware is well known for educational and practical projects (Raspberry Pi Foundation).

Bluetooth communication is made by a Rocketek RT-BT4 USB dongle, this adapter is equipped with the CSR8510 chipset, which makes it compatible with most libraries for Linux distributions, including Raspbian (free operating system based on Debian optimized for the Raspberry Pi hardware).

To communicate with the access controller a connection to the network is required, the board has a built-in Ethernet network interface, if a wired connection is not available it is possible to add a Wi-Fi USB dongle.

In addition, the Raspberry board has a general-purpose input/output (GPIO) interface with several pins, which can drive a relay. This makes it possible to control an electronic lock.

Figura 3: Raspberry board, with Rocketek RT-BT4 USB bluetooth dongle and relay module

5

3.3. Transmitting an iBeacon

BlueZ2 is official Linux Bluetooth protocol stack. It is an Open Source project distributed under GNU General Public License (GPL). BlueZ kernel is part of the official Linux kernel since version 2.4.6.

To act as iBeacon transmitter, following steps are necessary:

• Initialize and broadcast a signal

• Advertise but do not allow connections

• Broadcast a unique transmission

This is possible by the following commands:

hciconfig hci0 up

hciconfig hci0 leadv 3

hciconfig hci0 noscan

The broadcast has three important identifiers:

• Proximity UUID: a unique UUID that distinguishes your iBeacons from other iBeacons

• Major: used to group related sets of iBeacons

• Minor: used to identify a iBeacon within a group

The hcitool command configure the transmission to use a custom UUID, attaching 00 00 00 00 to the end of our UUID we set 0 for major and minor IDs, the last byte to add is the RSSI value of C8. The command should look like the following:

hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 63

6F 3F 8F 64 91 4B EE 95 F7 D8 CC 64 A8 63 B5 00 00 00 00 C8

Here more details:

1E

02 Number of bytes that follow in first AD structure

01 Flags AD type

1A Flags value 0x1A = 0001 1010

bit 0 (OFF) LE Limited Discoverable Mode

bit 1 (ON) LE General Discoverable Mode

bit 2 (OFF) BR/EDR Not Supported

bit 3 (ON) Simultaneous LE and BR/EDR to Same Device Capable (controller)

bit 4 (ON) Simultaneous LE and BR/EDR to Same Device Capable (Host)

2 http://www.bluez.org

6

1A Number of bytes that follow in second (and last) AD structure

Vendor specific values:

FF Manufacturer specific data AD type

4C 00 Company identifier code (0x004C = Apple)

02 Byte 0 of iBeacon advertisement indicator

15 Byte 1 of iBeacon advertisement indicator

Specific UUID values:

63 6F 3F 8F 64 91 4B EE 95 F7 D8 CC 64 A8 63 B5 iBeacon proximity UUID

00 00 Major

00 00 Minor

C8 00 Calibrated TX power

The example shows how to initialize the device, it is possible invoke the commands from the application running on Raspberry.

3.4. Controlling relay module

To control Raspberry Pi GPIO channels can be used the RPi.GPIO python module3, this package provides a class to control the GPIO on a Raspberry Pi.

With this library is simple to control a relay in few lines of code, in the following example we drive the opening of a switch for about half second.

First set up for channel (PIN) 12:

import RPi.GPIO as GPIO

GPIO.setmode(GPIO.BOARD)

GPIO.setup(12, GPIO.OUT)

To set an output high:

GPIO.output(12, GPIO.HIGH)

sleep(500.0 / 1000.0) # wait 500 ms

To set an output low:

GPIO.output(12, GPIO.LOW)

Clean up at the end of your program

GPIO.cleanup()

3 https://pypi.python.org/pypi/RPi.GPIO

7

4. SYSTEM OPERATION

When the checkpoint device is in operation, it emits an iBeacon. The transmitted proximity UUID is recognized from the mobile app running on the user’s device, which reacts automatically when in range. iBeacons are detected in background by the operating system of the mobile device, and the right app is started when necessary.

In presence of multiple checkpoint devices (so multiple iBeacons), different major and minor values are used to map the correct point.

To avoid accidental misuse and achieve higher security level, an user access code (PIN) or fingerprint identification is needed prior to run the app, these check may interfere with the app usability, so may be set by user’s preferences.

To “access” when we are in proximity of a checkpoint device, the mobile app sends the request to the server, if the user is authorized to access, an OTP is generated and sent to the checkpoint device. As the Bluetooth controller can transmit a single ID at time, it stops to announce the official UUID (that identifies the location) and change the transmission with a new UUID, containing two chunks 16-bit long of the OTP (A One-Time Password System, 1998).

OTP generated by the server is 64-bit long, the checkpoint divides it into four parts 16-bit long and selects two randomly. In this way it is possible to use the major and minor values (16-bit each) of the iBeacon message and broadcast the code for just few seconds, since the user is still in range.

The application detects a new iBeacon, containing the two pieces of the original OTP in major and minor fields, the request (containing these values) is resubmitted to the server that check the correctness. If all conditions are met, the command for driving the relay is sent to the checkpoint device. All requests are logged on the access controller server.

Fig. 4: System transactions

The two chunks of the OTP must not be in collision with major and minor values already used by the system to identify the checkpoint devices, for example: if we have two locations identified by (major: 1, minor: 1) and (major: 1, minor: 2) it must never be generated a code with those values.

8

As mentioned in section 2.4, the iBeacon frame is transmitted to everyone in a public plainly visible way, there are no security mechanisms. The use of a temporary code (from an OTP) is needed to avoid conflicts in case two or more users attempt to simultaneously send requests to the checkpoint device; it also ensures that the user is still in proximity of the iBeacon. During the transmission of the modified UUID, if another user comes within range of the iBeacon, his mobile app will receive major and minor values different from known IDs, therefore the message will be discarded and no interaction with the system will be started.

5. CONCLUSIONS

When the iBeacon technology was introduced, its use was oriented for micro-location marketing on mobile apps (to provide information or promotions as soon as a customer walk in a store, or nearby to a specific item).

In this paper we have described how iBeacon technology can be used in a more flexible and powerful way, this gives the opportunity to create new important applications to improve services or create new ones in the IoT4 field.

Normal users showed greater familiarity in the use of mobile devices (such as smartphones and tablets) rather than other tools. The pervasive spread of these new wearable devices pushes us to redefine new ways of interaction human-to-computer.

The prototype described can be taken into account also for applications in Smart Cities field.

4 Internet of Things (IoT) – system of interrelated computing devices, mechanical and digital machines, objects or people that are provided with unique identifiers and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction.

9

REFERENCES

A One-Time Password System. (1998, February). From IETF: https://tools.ietf.org/html/rfc2289

Garther. (2014, December). Gartner Predicts By 2017, 30 Percent of Smart Wearables Will Be Inconspicuous to the Eye. From http://www.gartner.com/newsroom/id/2941317

Google, Inc. (2016, April 14). Platform Overview | Beacons | Google Developers. From https://developers.google.com/beacons/overview

Raspberry Pi Foundation. (n.d.). What is a Raspberry Pi? From https://www.raspberrypi.org/help/what-is-a-raspberry-pi/