#382 Secure and cool Remote Controls (Touchless, AES128 encryption, with a T-Beam watch and a cat)

Using remote controls to switch something on or open your garage is a piece of cake. Doing this automatically without touching anything is a little bit cooler. And doing it like James Bond, with an ESP32 Watch and completely encrypted? Let’s have a closer look at how this can be done and how we can build secure transmissions for other projects.
I am a proud Patreon of @GreatScott!, @ElectroBOOM , @Electronoobs , @EEVblog , and others. No Docker, No Microsoft Teams, Zoom

Links:

The links above usually are affiliate links that support the channel (no additional cost for you).
If you want to support the channel, please use the links below to start your shopping. No additional charges for you, but I get a commission of your purchases to buy new stuff for the channel

Please do not try to email me. This communication channel is reserved for my primary job
As an Amazon Associate, I earn from qualifying purchases
#no#midroll#ads

[Hessijames]

Another approach would be a challenge-response one: S—„open“—>R, R—„please encrypt N=rand()–>S, S-AES(key, N)->R

[eide]

One of your best videos in terms of information density.
ESP-NOW is far too unknown, it has such a great potential and you can do so much cool stuff with it!
So thank you for this one, Andreas!

[AlunJones]

Since you're padding the packet with zeros, I suggest you validate that they decode to zeros at the receiving end. This protects you against an attacker sending random data in the hope it decrypts to a high value.

[LordHog]

Thumbs up for the fur ball. Very adorable

[klassichd]

Thanks for your effort and your ideas. These remote control activities are really extremely useful and worthwhile each penny.
For many years, I am opening (and close) my garage door via 20 EUR Homematic components (AES encrypted) and open (and lock) the entrance doors of the house using Keymatic together with a smart phone "App" written in "Tasker". Works very well and is very convenient. I also use RFID to trigger these tasker apps.
When my mother increased dementia and forgot her keys, I used additional RFID technology to give her access to her house. So, she could stay many months longer in her own house as without this technology. Very helpful and worthwhile each penny.

[PATRIKKALLBACK]

You are a lucky guy Andreas, my cat always sleep on the keyboard.

[PemboPemberton]

Use a similar principle to a keyless car fob.

(1) - The fob sends a command ID "request to unlock" - plus an incrementing value.

(2) - The car checks the ID and that the incrementing value is higher than the previous value and stores it if it is - then replies with an "understood unlock request" command plus a random number for the fob to perform some maths formula on.

(3) - The fob performs the needed maths formula on the value recieved, then sends the value back.

(4) The car checks that the value is a match for the result of the formula and unlocks if it is.

Just one of many methods.


Enjoying the channel from here in the UK.

😉👌🏾

[AnotherMaker]

Very cool use for the watch. I love the creativity. I may need to dust mine off and mess with it again. I made a few little silly projects, but it's been sitting ever since.

[CTCTraining]

Great project, only thing I’d add would be a status update on the garage door using another comms path entirely (eg text, or email) to let me know about any openings (or more usefully) failed closings.

[prof]

To improve securety as others have pointed out a challange response would be great. Also you might want to consider asymetric encryption. Have the transmittes public key register in the reciever.

[noslisteninganyway]

Some interesting project ideas. I've been wanting to create a secure garage door opener for my motorcycles and trigger it by flashing my high-beams when I get home. Toggling the high-beams can both power the units on and transmit the codes.

[bizmythy]

Maybe you could use the RTC to include the current time in the encrypted message so that if the code is milked and replayed later the time from the code will not match the RTC of the receiver. Would maybe need to update the transmitter's time occasionally to keep it accurate.

[Average_Geo]

Fun project with fair enough security. It's probably easier to pick a door lock to gain entry ;)

[Mr.Leeroy]

7:19 no, MITM jams receiver when you push the button, and retransmits second code it gets from your remote. All happens in a blink of an eye, so you may think that it was a glitch the first time, door still opens, but attacker still gains unused key for himself.

[kevinlassure]

Perfect video. I hope since your video, the AES implémentation now integrates "salt"

[peter.stimpel]

Nice content. The field of encryption is a tough one with many security traps and risks if not properly implemented. So guys, be careful how much you trust your own implementation or libraries.

[grindel]

After the really exciting contend, the snorring cat outro relaxed me again <3. So we have 1. excitement 2. relaxment and maybe next time again funny moments with you "little hand pointer"? :D great LIKE from germany <3

[sikedipuuhja]

if you have access to an RTC, just include a timestamp - unixtime format - into the message. this way you can also verify whether the message was prerecorded. keeping a +/-10 second window can solve problems related to small inaccuracies

[mcconkeyb]

Interesting project!
My add on would be to include the Date/Time with the counter value, then encrypt the whole thing. On the receive side, you have 2 variables to compare; 1 - is the counter incremented, 2 - is the time within the right range (the Date/Time range can be set by the user, depending on security level desired). The draw back here is that the system has to have a moderately accurate real time clock (RTC). If you are using a smart wrist watch that should be no problem for the transmitter. Since the receiver is likely hard mounted to some fixed infrastructure (like a garage, etc) there should be a power source that is adequate to run a RTC in the receiver.
With this addition in place, a bad guy will have a very limited amount of time to find the encryption key, decode the counter value and then increment it and send the new encrypted message back to your receiver to open you door. Still not impossible to do, but considerable harder.
After posting this I scrolled down to see this idea had already been posted. Oh well, better late than never. :-)

[craigs]

I think one needs an upper bounds on the decrypted counter, without that there is likely chance that a random generated encryption string decode may be larger than the counter and open the door. Depending in the current counter value it's the probability of the decrypted random numbers being below the counter value vs it being above is the counter. If the counter value was at 1 all numbers but 0 or 1 would open the door. Very significant probability any random encrypted string would resolve to > than 0 or 1.