Hi Raspberry Pi Community,

I would like to use radio remote’s control to trigger an events on my Raspberry pi.

I guess I’ll go with 433Mhz as I believe they are the most common available ?

So I will need a 433Mhz RX/TX Module to connect on the GPIO, so far I get it…

But how properly secure the communication between those remotes and the RPI to avoid any anyone to sniff the transmitting and replay it. In other words spoof it.

Wubba Lubba dub-dub…

  • hendrik@palaver.p3x.de
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    3 days ago

    You’d use one of the rolling code mechanisms like in a keyless entry system, garage door opener or a car key fob. Maybe symmetric or asymmetric cryptography instead or on top. Depends on the exact use-case. But you’d have to build the remote yourself, I don’t think that’s in the readily available consumer products.

    If you want it less complicated, have a look at Bluetooth or ESP-NOW. Wifi and Bluetooth and other protocols have encryption handled for you.

  • elmicha@feddit.org
    link
    fedilink
    English
    arrow-up
    2
    ·
    3 days ago

    Does it have to be radio? Maybe infrared would be enough? You could use a TSOP 2438 as a receiver and any old IR remote.

  • Zachariah@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    1
    ·
    3 days ago

    Might be a good use for PGP. The signal can be snooped and spoofed, but the messages should be end-to-end encrypted.

    • ExperimentalGuy@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 days ago

      Only problem with just using just pgp is that the signal would be vulnerable to a replay attack. I feel like a rolling code that’s encrypted using PGP might be the way so that the replay attack part is gotten rid of.

      All that’s to say, there’s probably some technical paper that details the best way to set up a system like this.

      • Zachariah@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        3 days ago

        Could it only accept serialized messages? Once it’s received a message, never accept the same exact message again.

        • tapdattl@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          2 days ago

          Well then you’d have to keep track of all messages recieved. An easier option might just be to sign the current system time, make sure the clocks are synchronized, and accept a +/- 1 second wiggle

          • Zachariah@lemmy.world
            link
            fedilink
            English
            arrow-up
            2
            ·
            2 days ago

            Wouldn’t it just need to know which is the highest message number it has seen? And then don’t accept that one or any lower ever again?

            If the count is within the encrypted message, no one can spoof anything higher.

  • RandomUser@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    3 days ago

    Rolling codes may protect you from a replay attack, but if the attacker is more sophisticated and has worked out the algorithm, then they can send the commands and effectively lock you out.

    Is Bluetooth no good? Lots of protection baked in already.

    • ulterno@programming.dev
      link
      fedilink
      English
      arrow-up
      0
      ·
      2 days ago

      Is Bluetooth no good? Lots of protection baked in already.

      Well, if you have a 2 way communication capability anyway, it’s not particularly difficult to implement a key exchange, followed by data transmission using a temporary key, similar to HTTPS