This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Using BLE to automate gate opener

Our homeowners association has a gate which opens when a transmitter in the car is pushed. I would like to add a BLE device to the gate which would trigger the gate to open when it detects a vehicle it knows about. I imagine it consisting of two parts:

  1. A beacon placed in the car. This is easy to do with the SDK.
  2. A receiver of the beacon hooked to the gate electronics to trigger a relay to open the gate.

Are there existing applications that can be easily modified to support this scenario? Creating a beacon is easy enough but I wonder about support for receiving beacons using the SDK. Is this possible? Pointers to relevant documentation would be appreciated.

A related question would it possible to detect the built-in car bluetooth instead of a beacon or is the car bluetooth incompatible with BLE?

  • Just using a beacon to open your doors would open your system to replay attacks. I would only need a sniffer and I could just copy the signal emitted by a car.

    Usually, you would add some kind of chalange. For example, receiving an encrypted random number by the gate and then sending back the decrypted random number to the gate and thus proving the knowledge of a secret key.

  • Hi.

    While there is probably no pure "Observer listening to (i)Beacons" example in nRF5 SDK (maybe somewhere on GitHub?) it's quite easy to develop one. Because broadcasting precedes every BLE connection basically every GAP Central example in SDK contains code which listens to "beacons". Just by modifying the parser of adv. data you can achieve that it will listen to your kind of beacon (whatever you plan to put into data).

    When it comes to "car built-in Bluetooth" then it's almost certainly NOGO. All BT handsfree use BT Classic (BR/EDR) A2DP profile and while some may have other services/profiles and maybe even BLE (similar to latest gadgets like Samsung TVs which for some reason - probably user experience with certain Samsung peripherals - broadcast BLE advertisements all the time) you will hardly get access to the data.

    Side note on intended application: if you care about security at all then you should realize soon that opening something just based on one-way broadcasts is kind of silly and spoofable by any 12-year-old kid with little bit of internet searching skills. The analogy is with current infra and sub-GHz radio systems to open the garage door: the only decent secure options are those which have "rolling key" meaning they send one-time generated sequence of at least 60 bits which must match with one of expected sequences generated in the door controller. This works if you don't press button on the key accidentally too many times because door keeps typically 10-500 upcoming codes and once it matches it synchronizes for the next round. Now with BLE it's impossible to let broadcaster sending sequences of valid codes all the time because a) it's easily captured and misused by the attacker and b) the sequence would advance very fast so window of valid codes would be insane, it would not fit into the memory or it would start to break security of these few-bit-long one-time passwords etc. In addition it would be even more vulnerable to "steal one code by disturbing the spectrum and then just keep rolling with the key so attacker keeps always one spare next key for his use" attack, simply because broadcasted data are valid and any device can pretend to be sending them as genuine key. If you would build such system and be commercially successful probably I would be the first who would release open source FW example for off-the-shelf cheap HW (such as Nordic Dev Kit) which would be listening to the key, emitting noise to prevent door from capturing the packet and then each time the key sends new code I would repeat the sequence but then sending the previous to the door so it would look like your system works as usually but you have no idea that attacker has always one valid key in the pocket and once you leave for a while he will enter the garage and steal everything.

    All in all the only secure solution for your app with BLE would be some sort of Time based OTP broadcast (still vulnerable to some attacks but probably fine for the level of security you need) or better bi-directional communication exchange based on some well tested authentication scheme (e.g some of NIST approved schemes based on AES or ECC keys and primitives). Still doable with nRF5x but looks like several weeks (or maybe months) of hard work on FW development for both door and key.

    In every case good luck!

  • This isn't a door but a gate to a neighborhood so security of communication is not critical. If someone wanted in all they have to do is wait for someone to open the gate and drive in after them instead of sitting there with a sniffer. A beacon with an encrypted payload and sequence number could be used though to secure it if needed against replay attacks so two-way wouldn't be needed. Still would like to receive beacons using the SDK though.

  • Quite obvious question: standard beacon advertises all the time with period of 20-500ms so how you would synchronize these sets of valid "encrypted" payloads? They would have many thousands of records for each key you want to keep in the memory and that still assumes that the keys would sync with gate every day (because only with 5 packets a second it makes almost half a million codes per key per day;). I'm afraid you are building simply "convenient" opener which will open to any BLE signal which goes around and that means you can very well remove the gate and solve the problem;)

  • Thanks for the pointer to use central and sniff on advertisements. As for security all your points are valid but this is for convenience since there is really nobody keeping someone following an existing owner into the neighborhood. It's mainly to prevent the drive-by opportunistic entry. For security though, a simple advertisement with a 32 bit sequence number and encrypted payload using the sequence number, clock time, and secret should allow 1 second changing for 30 years. The receiver just has to keep track of the last valid one it received for each device. Storing the last message for 50 beacons shouldn't stress storage. Yes, you could sniff my beacon while I'm at work and drive over to our gate. Sort of like the one-way token generation used for two-factor authentication. Heck, there is probably a standard for this one-way token based on time and secret.

Related