Door Bell 2.0 — IoT Door Bell

What is Door Bell 2.0?

Door Bell 2.0 (or DoorBell20 for short) is a Bluetooth Low Energy (BLE) appliance to monitor a door bell and send notifications whenever the door bell rings. It turns a conventional door bell into a smart door bell that can be connected to the Internet of Things (IoT)., e.g., using the DoorBell20 If This Then That (IFTTT) client. Thus, DoorBell20 is the modern version of a door bell, or, as the name suggests, the door bell version 2.0 for the IoT era.

Full source code and hardware design is available at GitHub.

DoorBell20 consists for two major parts:

  • The DoorBell20 monitoring device, which is connected in parallel to the door bell and wirelessly via BLE to a client running on a remote IoT gateway, e.g., a Raspberry Pi with Bluetooth stick.
  • A DoorBell20 client running on the IoT gateway passing on notifications received via BLE to a remote cloud service. Different clients can be implemented for different IoT cloud services. So far, DoorBell20 includes a client for If This Then That (IFTTT), which makes it very easy to trigger different actions when a door bell event is detected. For instance, a notification can be sent to a mobile phone or trigger an IP camera installed at the door to take pictures.

The following ASCII art shows the big picture of how DoorBell20 works.

                  [IoT Cloud Service]
                  [  (e.g., IFTTT)  ]
                           | ^
                 Internet  | | Door Bell Event Notifications
                           |
                [      IoT Gateway      ]
                [ w/ DoorBell20 Client  ]
                [ (e.g., IFTTT Trigger) ]
                           |  ^
           BLE Connection  |  | Door Bell Event Notifications  
                           |
|___________[DoorBell20 Monitoring Device]_________|
|                                                  |
|____________________[Door Bell]___________________|
|                                                  |
|                                                  |
|                                                 \   Door Bell Push Button
|                                                  \
|                                                  |
|________________(Voltage Source)__________________|
                 (    12 VAC    )

The following images show the DoorBell20 monitoring device, its connection to a door bell, and a door bell event notification displayed by the If This Then That (IFTTT) app on a mobile phone.

doorbell20_monitoring_device2

DoorBell20 monitoring device

DoorBell20 device connected to door bell.

DoorBell20 device connected to door bell.

IFTTT client showing door bell event notification.

IFTTT client showing door bell event notification.

The main features of DoorBell20 are:

  • Open-source software and hardware. Source code for the door bell monitoring device and IFTTT client as well as Eagle files (schematic and board layout) are provided.
  • Maker-friendly: using easily available cheap standard components (nRF51822 BLE chip, standard electronic parts), easy to manufacture circuit board, and open-source software and hardware design.
  • Includes a client for the popular and versatile If This Then That (IFTTT) service to facilitate the development of IoT applications integrating DoorBell20.
  • Liberal licensing of software and hardware under the Apache License 2.0 and the CERN Open Hardware License 1.0, respectively.

DoorBell20 Monitoring Device

The following images show the DoorBell20 hardware and schematic:

DoorBell20 monitoring device

DoorBell20 monitoring device

 

DoorBell20 monitoring device

DoorBell20 monitoring device

Schematic of DoorBell20 device

Schematic of DoorBell20 device

The DoorBell20 monitoring device is based on the BLE chip nRF51822 by Nordic Semiconductors. The nRF51822 features an ARM Cortex M0 processor implementing both, the application logic and the BLE stack (so-called softdevice). DoorBell20 uses the S110 softdevice version 8.0. See next sub-section on how to flash the softdevice and the application code. We use a so-called “Bluetooth 4.0″ breakout boards with an nRF51822 (version 3, variant AA w/ 16 kB of RAM and 256 kB flash memory) and two 2×9 connectors (2 mm pitch), which you can buy over the Internet for about 6 US$ including shipping.

We isolate the 12 VAC door bell circuit from the microcontroller using an opto-isolator. A rectifier and 5 V voltage regulater is used to power the LED of the opto-isolator whenever the door bell is ringing. A GPIO pin of the nRF51822 connected to the other side of the opto-isolator is then detecting the event. In addition to the integrate protection mechanisms of the LM2940 voltage regulator (short circuit and thermal overload protection, shutdown during transients), a varistor protects from voltage transients since many door bells are inductive loads inducing voltage spikes when switched off. Since varistors age with every voltage transient, a fuse is added to protect the door bell circuit from a short circuit of the varistor.

The nRF51822 is powered by two AA batteries. No additional voltage regulator is required, which increased the energy efficiency, and the monitoring device is expected to run for years from a pair of AA batteries. Note that we did not implement a reverse polarity protection, so be careful to insert the batteries correctly.

The schemtic and circuit board layout (PCB) of the DoorBell20 monitoring device for Eagle as well as the firmware can be found at GitHub. We deliberately used a simple single-sided through-hole design to help makers producing their own boards.

IFTTT DoorBell20 Client

DoorBell20 can be connected to any BLE client running on a remote machine. After receiveing a BLE notification about a door bell event, the client can then trigger local actions, and can forward the event to a remote IoT cloud service. DoorBell20 comes with a client for connecting to the popular If This Then That (IFTTT) cloud service.

Whenever a notification for a door bell alarm is received, a web request is sent to the IFTTT Maker Channel triggering an event with a pre-defined name. You can then define your own IFTTT recipes to decide what to do with this event like showing a notification on your smartphone through the IFTTT app, as shown in the following image.

IFTTT client showing door bell event notification.

IFTTT client showing door bell event notification.

For further technical details, please have a look at the documentation and source code provided at GitHub.

Key 2.0 — Bluetooth IoT Door Lock

What is Key 2.0?

Key 2.0 (or Key20 for short) is a Bluetooth IoT Door Lock. It turns a conventional electric door lock into a smart door lock that can be opened using a smartphone without the need for a physical key. Thus, Key20 is the modern version of a physical key, or, as the name suggests, the key version 2.0 for the Internet of Things (IoT) era.

Key20 consists of two parts:

  1. Door lock controller device, which is physically connected to the electric door lock and wirelessly via BLE to the mobile app.
  2. Mobile app implementing the user interface to unlock the door and communicating with the door lock controller through BLE.

You can get a quick impression on how Key20 works by watching the following video:

The following image shows the Key20 door lock controller device and the Key20 app running on a smartphone.

Key 2.0 App and Door Lock Controller Device

Key 2.0 App and Door Lock Controller Device

The main features of Key20 are:

  • Using state-of-the-art security mechanisms (Elliptic Curve Diffie-Hellman Key Exchange (ECDH), HMAC) to protect against attacks.
  • Open-source software and hardware, including an open implementation of the security mechanisms. No security by obscurity! Source code for the app and door lock controller as well as Eagle files (schematic and board layout) are available on GitHub.
  • Maker-friendly: using easily available cheap standard components (nRF51822 BLE chip, standard electronic parts), easy to manufacture circuit board, and open-source software and hardware design.
  • Works with BLE-enabled Android 4.3 mobile devices (and of course newer versions). Porting to other mobile operating systems like iOS should be straightforward.
  • Liberal licensing of software and hardware under the Apache License 2.0 and the CERN Open Hardware License 1.0, respectively.

Security Concepts

A door lock obviously requires security mechanisms to protect from unauthorized requests to open the door. To this end, Key20 implements the following state of the art security mechanisms.

Authorization of Door Open Requests with HMAC

All door open requests are authorized through a Keyed Hash Message Authentication Code (HMAC). A 16 byte nonce (big random number) is generated by the door lock controller for each door open request as soon as a BLE connection is made to the door lock controller. The nonce is sent to the mobile app. Both, the nonce and the shared secret, are used by the mobile app to calculate a 512 bit HMAC using the SHA-2 hashing algorithm, which is then truncated to 256 bits (HMAC512-256), and sent to the door lock controller. The door lock controller also calculates an HMAC based on the nonce and the shared secret, and only if both HMACs match, the door will be opened.

The nonce is only valid for one door open request and effectively prevents replay attacks, i.e., an attacker sniffing on the radio channel and replaying the sniffed HMAC later. Note that the BLE radio communication is not encrypted, and it actually does not need to be encrypted since a captured HMAC is useless when re-played.

Moreover, each nonce is only valid for 15 s to prevent man-in-the-middle attacks where an attacker intercepts the HMAC and does not forward it immediatelly but waits until the (authorized) user walks away after he is not able to open the door. Later the attacker would then send the HMAC to the door lock controller to open the door. With a time window of only 15 s (which could be reduced further), such attacks are futile since the authorized user will still be at the door.

Note that the whole authentication procedure does not include heavy-weight asymmetric crypto functions, but only light-weight hashing algorithms, which can be performed on the door lock device featuring an nRF51822 micro-controller (ARM Cortex M0) very fast in order not to delay door unlocking.

With respect to the random nonce we would like to note the following. First, the nRF51822 chip includes a random number generator for generating random numbers from thermal noise, so nonces should be of high quality, i.e., truly random. An attack by cooling down the Bluetooth chip to reduce randomness due to thermal noise is not relevant here since this requires physical access to the lock controller installed within the building, i.e., the attacker is then already in your house.

Secondly, 128 bit nonces provide reasonable security for our purpose. Assume one door open request per millisecond (very pessimistic assumption!) and 100 years of operation, i.e., less than n = 2^42 requests to be protected. With 128 bit nonces, we have m = 2^128 possible nonce values. Then the birthday paradox can be used to calculate the probability p of at least one pair of requests sharing the same nonce, or, inversely, no nonces shared by any pair of requests. An approximation of p for n << m is p(n,m) = 1 – e^((-n^2)/(2*m)), which practically evaluates to 0 for n = 2^42 and m = 2^128. Even for n = 2^52 (one request per us; actually not possible with BLE), p(2^52,2^128) < 3e-8, which is about the probability to be hit by lightning, which is about 5.5e-8.

Exchanging Keys with Elliptic Curve Diffie Hellman Key Exchange (ECDH)

Obviously, the critical part is the establishment of a shared secret between the door lock controller and the mobile app. Anybody in possession of the shared secret can enter the building, thus, we must ensure that only the lock controller and the Key20 app know the secret. To this end, we use Elliptic Curve Diffie-Hellman (ECDH) key exchange based on Curve 25519. We assume that the door lock controller is installed inside the building that is secured by the lock—if the attacker is already in your home, the door lock is futile anyway. Thus, only the authorized user (owner of the building) has physical access to the door lock controller.

First, the user needs to press a button on the door lock controller device to enter key exchange mode (the red button in the pictures). Then both, the mobile app and the door lock controller calculate different key pairs based on the Elliptic Curve 25519 and exchange their public keys, which anyone can know. Using the public key of the other party and their own private keys, the lock controller and the app can calculate the same shared secret.

Using Curve 25519 and the Curve 25519 assembler implementation optimized for ARM Cortex-M0 from the Micro NaCl project, key pairs and shared secrets can be calculated in sub-seconds on the nRF51822 BLE chip (ARM Cortex M0).

Without further measures, DH is susceptible to man-in-the-middle attacks where an attacker actively manipulates the communication between mobile app and door lock controller. With such attacks, the attacker could exchange his own public key with both, the lock controller and the app to establish two shared secrets between him and the door lock controller, and between him and the mobile app. We prevent such attacks with the following mechanism. After key exchange, the mobile app and the door lock device both display a checksum (hash) of their version of the exchanged shared secret. The user will visually check these checksums to verify that they are the same. If they are the same, no man-in-the-middle attack has happened since the man in the middle cannot calculate the same shared secret as the door lock controller and the mobile app (after all, the private keys of door lock controller and mobile app remain private). Only then the user will confirm the key by pressing buttons on the door lock controller and the mobile app. Remember that only the authorized user has physical access to the door lock controller since it is installed within the building to be secured by the lock.

The following image shows the mobile app and the door lock controller displaying a shared secret checksum after key exchange. The user can confirm this secret by pushing the green button the the lock controller device and the Confirm Key button of the app.

Key 2.0: key checksum verification after key exchange.

Key 2.0: key checksum verification after key exchange.

Why not Standard Bluetooth Security?

Actually, Bluetooth 4.2 implements security concepts similar to the mechanisms described above. So it is a valid question why don’t we just rely on the security concepts implemented by Bluetooth?

A good overview why Bluetooth might not be as secure as we would like it to be is provided by Francisco Corella. So we refer the interested reader to his page for the technical details and a discussion of Bluetooth security. We also would like to add that many mobile devices still do not implement Bluetooth 4.2 but only Bluetooth 4.0, which is even less secure than Bluetooth 4.2.

So we decided not to rely on Bluetooth security mechanisms, but rather implement all security protocols on the application layer using state of the art security mechanisms as described above.

Bluetooth Door Lock Controller Device

The following image shows the door lock controller and its components.

Key 2.0 Door Lock Controller Device

Key 2.0 Door Lock Controller Device

The Door Lock Controller Device needs to be connected to the electric door lock (2 cables). You can simply replace a manual switch by the door lock controller device.

The door lock controller needs to be placed in Bluetooth radio range to the door and inside the building. Typical radio ranges are about 10 m. Depending on the walls, the distance might be shorter or longer. In our experience, one concrete wall is no problem, but two might block the radio signal.

The main part of the hardware is an nRF51822 BLE chip from Nordic Semiconductors. The nRF51822 features an ARM Cortex M0 micro-controller and a so-called softdevice implementing the Bluetooth stack, which runs together with the application logic on the ARM Cortex M0 processor.

An LCD is used to implement the secure key exchange procedure described above (visual key verification to avoid man-in-the-middle attacks).

For more technical details including schematics, board layout, and source code please visit the Key20 GitHub page.

Android App

The app requires a BLE-enabled mobile device running Android version 4.3 “Jelly Bean” (API level 18) or higher.

The following images show the two major tabs of the app: one for opening the door, and the second for exchanging keys between the app and the door lock controller.

Key 2.0 App: door unlock tab

Key 2.0 App: door unlock tab

 

Key 2.0 App: key exchange tab

Key 2.0 App: key exchange tab

The source code is available from the Key20 GitHub page.