Problem

In order to maximize battery life, BLE sensors may send data as non-connectable undirected advertisements, the classic beacon type transmission. In this use case, there is a vulnerability that advertisements can be captured by a third party and replayed. MAC addresses can be easily spoofed, leading to unreliable data on the observer end.

Project

The example BLE Gateway and BLE Sensor is an attempt at mitigating the vulnerability to replay attacks when using beacon type advertisements. It's written for nRF51822 hardware with no onboard NVRAM. The lack of permanent storage weakens this scheme because of start-up conditions. I'll also point out where this scheme is not a proof against replay attacks, only detecting and mitigating certain types of attempts

The assumption is that sensors even in sleep mode retain memory and timers. On the nRF51822, this is reasonable, as the sleep current is only 4uA. On power-on, sensors capture their power-on time as zero. Subsequent advertisements embed a 2-byte value indicating the number of seconds since power-on. This "spoof clock" resets at 1800 seconds (or 30 minutes), due to the limitations of the mbed implementation of timers on the nRF51822. Every new advertisement is basically timestamped with when that advertisement event happened relative to the sensor's "birthday", with a birthday periodicity of 1800 seconds.

When the observer reads the sensor data and timestamp, it can calculate when the sensor's birthday is relative to it's own timer. The observer stores an array of MAC address and birthday pairs. A sensor's advertisement is considered non-suspicious if the sensor's birthday calculated from the advertisement's timestamp matches this array. On powerup with a blank array, the gateway has no other option than to trust all new MAC address advertisements.

But it's expected that sensors would need to have their batteries switched out eventually. Any power off-to-on cycle will reset the birthday of the sensor and so its advertisements would have timestamps that conflict with the observer's recorded birthday for that MAC address. I extended the observer's birthday records with a secondary set of birthdays. When there is a conflict, the new birthday is recorded into this second record. If there are 3 consecutive transmissions where the birthdays are consistent, then I can consider this sensor's birthday as the new primary birthday and start accepting data timed at this new birthday. The birthday records are implemented as a FIFO.

I don't change the time values on every repeated advertisement, and the gateway may receive any of the several repeated advertisements during the advertisement interval. As a result, the gateway must accept a several seconds long range around the birthday time. This also accounts for timer drift between sensors and gateways before resyncing. It does mean that the spoof detection is weaker than a scheme where every advertisement packet has an updated time and modules have an actual external real time clocks with greater accuracy.

Here's my advertisement organization

The first 5 bytes are the standard AD1 block for beacons, indicating the advertisement is unconnectable undirected. AD2 block is our manufacturer specific custom advertisement where we pack data. Bytes 5-8 are our indicator for the observer being able to identify "our sensor" vs. other beacons using a pattern matching scheme. The observer will only process the data (perform AES decrypt and output data over serial) if these 4 bytes match our pattern. The alternative is to know which MAC addresses to look for ahead of time. This would make deployment more complicated. The pattern matching is a compromise between security and ease of deployment. It imposes a weakness to the replay detection because the size of the spoof checking array is finite. We can only keep track of, say 50, unique MAC's and their birthdays. Beyond that, the FIFO starts dropping old MAC addresses, and malicious advertisements can then be injected. We'll detect when this happens, but we're not able to protect against it in an automated way. A solution for this is to have an external step to validate MAC addresses and protect those from dropping off the FIFO. But that's a lot of work.

Bytes 9-12 hold the battery voltage. I didn't want to take up more of the AES encrypted block for something that's not very sensitive.

The first two encrypted bytes, Byte 15-16, hold the number of seconds since the sensor's birthday.

Byte 17 holds the transmit counter. This helps the gateway differentiate between repeated transmissions of the same advertisement data, and not send those out the uart.

Byte 18-30 hold JSON formatted sensor data. Using JSON isn't very byte-efficient. But it pretty flexible and the scheme works well with MQTT topic naming.