Close
0%
0%

Secure wireless remote

A more secure RF wireless remote (like a garage door opener)

Similar projects worth following
Sparkfun recently published a guide to make a truly secure garage door opener (https://learn.sparkfun.com/tutorials/secure-diy-garage-door-opener/all). Their effort is laudable, but their protocol requires both ends to have transmit and receive capabilities and a full switch event requires two complete round trips. I think this can be made simpler without sacrificing (much) security.

Sparkfun's design uses LoRA radios, which has library support for Arduino that makes it very easy to send and receive complete packets. If you're going to go that way, then it makes sense that they designed a multi-packet exchange. And there's nothing at all wrong with the security of their system. In their protocol, the remote requests a nonce from the base station, and then it signs the nonce with the securely maintained EC private key and sends the signature over the nonce back to the base. Given that the crypto chip they're using can create secure random nonces and can properly safeguard the EC private key, the result is a system that's quite secure.

This is in stark contrast to the current state of the art garage door openers that are designed around a rolling code. With those, the transmitter maintains a counter that increments every time you push the button. The receiver keeps a matching counter and advances the counter to match the remote when a reception takes place. This prevents code replay attacks, but a novel attack on such systems is known as "rolljam." In a rolljam attack, an intermediary intercepts a transmitted code and suppresses (jams) it to keep it from being received. This first transmission doesn't result in a reception, so (presumably) the user will retry, sending a second transmission. The intermediary captures and suppresses this transmission as well, but then transmits the first code that was intercepted. The door opens and the legitimate user is satisfied. Once the legitimate user leaves, the intermediary can transmit the cached second code and open the door.

The problem with traditional rolling code is that the codes don't expire, which is what allows rolljam to succeed. The fix, therefore, is to trade out the simple counter for a timestamp. You have to permit a small amount of slop, but in general, if your attack window is only a minute or two, it makes any practical rolljam attack moot.

In this design, we retain the ATECC108A chip for the purpose of performing the ECDSA signature. This replaces the traditional PRNG/hash that is used in ordinary rolling code systems. In addition to this, we add a precision RTC chip on both sides. The DS1374C keeps time within 10 ppm, which should be accurate to about 5 minutes a year, worst-case. If we calibrate the current receiver clock drift every time you push the button, then long term accuracy isn't likely to be much of an issue.

The RTC doesn't actually have to be set. It just needs to count seconds from some arbitrary epoch. When you pair the transmitter to the receiver, the receiver takes note of whatever the timestamp is and compares that to its own RTC, storing the current delta as part of the "identity" of the transmitter (along with the transmitter's public key). The DS1374C was specifically chosen because it keeps time with a simple 32 bit counter rather than as a timestamp. This saves us having to convert time and date back to such a counter.

The message from the transmitter consists of the EC public key, the current RTC timestamp value, and an ECDSA signature over those two using the EC private key.

The receiver verifies that the public key in the message belongs to a paired remote, then validates that the signature is correct. It then verifies that the timestamp is within an acceptable window, and then updates that receiver's timestamp delta and drift and then triggers the authorized action.

To pair, the user presses the "pair" button and then the transmit button on a remote. The receiver collects the message, verifies the signature then calculates the timestamp delta and stores that and the public key in the paired transmitter list.

Because this is a simple, one-way protocol, there's no need for the complexity of LoRA. A simple OOK 10-20 kbps digital radio is all that's required. The SI4x55 chipsets include a standalone transmitter and receiver chip.

The downside of the combination of the DS1374, the ATECC108A...

Read more »

Adobe Portable Document Format - 48.47 kB - 03/15/2020 at 19:51

Preview
Download

  • Initial design work

    Nick Sayer03/15/2020 at 20:14 0 comments

    I've spent some of the COVID-19 quarantine alone-time sketching out the initial design. The schematic in the files section represents the beginning of the transmitter. The receiver is mostly the same except for the power supply section. That will wind up having a simple LDO power supply from some sort of AC input along with SSRs for outputs instead of buttons.

    The design includes a boost converter to turn a pair of AA batterie into a constant 3.3v power supply. The design at present calls for the boost converter to run constantly and hopefully with a low enough load the batteries will last long enough to not be a nuisance. If that doesn't work out, then we'd have to come up with some other scheme for backup power to the RTC chip and a MOSFET system to turn the power supply on and off when the button(s) are pushed. Hopefully it won't come to that.

    The RTC chip has a supercap for backup power, and the chip can be internally configured to trickle-charge the cap. This is only necessary to carry over the time counter whenever the batteries are changed.

    The schematic has connections for up to 4 buttons. The message to the receiver will include an 8 bit "message" field that can be used for future expansion. A secp256r1 public key is 2 32 byte numbers and an ECDSA signature is 96 bytes long. The time counter is 4 bytes long and the message byte is 1. That is a full packet size of 165 bytes, or 1320 bits (a 1 or 2 byte CRC might be appended just to cut down on the amount of verification work the receiver needs to do. A CRC check is a lot easier than an ECDSA signature test). At 10 kbps, that's just over 1/8 of a second or so, which ought to be just fine. A single button push would be a second or two, and would accommodate easily a half dozen retransmissions, of which you'd hope at least one would go through.

    The downside so far is that the DS1374C is kind of expensive - about $5 each. The other chips are pretty inexpensive by comparison, though we haven't even begun to talk about the radio yet.

View project log

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates