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...