Securing Movesense Sensor

This document describes the security environment of the Movesense sensor, and provides list of several methods to protect the sensor from un-intended access and modification.

Development sensor

As a starting point, it is useful to study the Movesense development sensor that is shipped in the Movesense development kit. For a developer, it is important that there are no obstacles when trying out different applications and use cases, and any extra security hinders the development effort. Therefore the development sensor is provided as open (read: insecure) as possible. This means that all the following are allowed by default:

• Any sensor can be accessed by anyone over the air

  • unbonded BLE connection ¹
  • Access to any service and protocol provided by the sensor is allowed by default

• Any firmware can be updated to a sensor by anyone (firmware update over BLE)

  • DFU can be started over BLE using Whiteboard protocol
  • DFU can be started manually using the recovery mode with battery removal and stud contacts

• Sensor internal flash can be read by anyone

  • Over BLE using custom firmware (see: firmware update above)
  • Using SWD pins on the sensor PCB under the battery

• Sensor data memory (EEPROM or Flash) can be read by anyone over BLE connection

=> There is essentially NO SECURITY on the developent sensor

Securing production Movesense Sensor

While the development sensors are open, the final products using Movesense sensors, should be not. In practice it is almost impossible to create 100% secure system (unless it is really simple), so a risk based analysis should be used in determining the best ways to counter the possible attacks.

Here we have collected a list of steps that can be taken in order to secure different "assets" (like internal flash memory) on the Movesense sensor.

Securing Internal flash

The internal flash can be read & written by: 1. bootloader during DFU process 2. Application firmware (can modify product data and sensor settings) 3. All of the internal flash can be read and modified using the SWD (debugging) port.

Securing DFU updates

Securing accesses 1 & 2 above can be achieved by preventing DFU with un-authorized firmware packets. Movesense 2.1 and above provide a metohod for that called “per-product bootloader”. The per-product bootloader means that your sensors can only be updated with the firmware developed by you over the air.

Securing SWD access

Preventing SWD access is possible writing 0xFFFFFF00 to the UICR_APPROTECT -register. This can be included in the firmware code using a following declaration in c/c++ -file:

const uint32_t __attribute__((at(0x10001000+0x208))) APPROTECT_SETTING = 0xFFFFFF00;

Setting APPROTECT prevents any reading or writing of internal flash of the MCU unless the whole chip is fully erased first.

(There is an attack using voltage glitching, that can allow technically savvy attacker to by-pass internal flash protection.)

Securing BLE-traffic

The Movesense sensor sends and receives data and commands over BLE radio link. To prevent unauthorized reading of data, or sending unauthorized commands, the following methods can be used:

BLE bonding

BLE Bonding can be enabled on the connecting device (Android, iOS is not supported), and by adding line

BLE_REQUIRE_BONDING(true)

in the App.cpp -file of the firmware.

• BLE bonding causes an encrypted communication which prevents clear-text snooping of traffic.
• Reduce chance of un-authorized re-bonding by selecting appropriate “BondingPolicy” and minimizing/removing RecoveryTime in /Comm/Ble/Security/Settings -API.
• Prevent harm of hijacked BLE connection by adding mutual authentication of sensor and mobile in the beginning of the connection. If authentication is not performed, disconnect the connection after small timeout

BLE Advertising data

If your firmware sends data using BLE advertising packets, those packets are available for all to read. If the data contained is considered sensitive, it is a good idea to encrypt the data before broadcasting it and decrypt it in the receiving device.

DataMemory

When data is written in data memory (Flash or EEPROM depending on the Movesens variant), whether using DataLogger/Logbook or using proprietary logic (low level EEPROM access), it can be read by replacing the sensor firmware with a compromised firmware. To protect agains the possibility of leaking the data this way, it is possible to add encrypting layer before writing data to DataMemory. That way the data can be only decrypted by an authorized party like cloud service or mobile device.

Debug logs

To prevent unintentional information of firmware operation from leaking, either via SWD or bluetooth, debug messages should be disabled. System debug messages are always disabled when build mode is "Release", so that is recommended for production firmwares. If DebugService is not needed (on field diagnostics), it is a good idea to disable that as well.