Encrypt UDP packet with time-generated encryption key

Question

I'd like you to help me solve a dilemma of mine. I am currently building a home automation from scratch for my next house.

The basic gist of it is that I will send UDP packets over a local network.

I created the clients in Electron/Web App (so Js backend) and also used a RPi with a C program(I can change the language to something else if necessary) as the server with the database. The client will send a ~10byte package to the server. Speed is key here, and from my testing, over Wi-Fi turing on a LED is almost as fast (to the human eye) as a normal light switch. So I'd like to keep my speed.

Since the packets will hold string that basically say "turn on this light in this room" or "lock the door and activate the alarm" or "change the temperature in that room" I obviously need to encrypt the package, thus I arrived here.

Here is what I tried or thought of so far:

• Use (D)TLS to send the Packages. While this would normally be a good idea, the libraries for it in JavaScript, Python or C are junk. There is no Python 3 library and the JavaScript's documentation is basically non-existant. One more thing to note is that this whole ordeal will be on a local network, so I don't know quite sure how to distribute the certificates in a secure way so they can't be replicated.
• Use TLS and switch to TCP. This would probably be a good idea but the overhead of TCP and TLS seem so big in comparison to my mere 10byte packet. Again, the certificate issue rises up, since I don't know how to make a DIY CA.
• Encrypt the packets with AES256. I wanted to do this until I realized that I don't have an extraordinarily good way to store the encyption key. I don't know how secure it is to store the key in plaintext in something like a NodeJS app. It a tad better in the binary of my C program but that is still not bulletproof. Maybe encrypting it in a file, but how do I keep that file safe.
• The most secure thing to me is to still use AES256 but generate the key based on some factors like: a passphrase, the time, the server's and client's IP address "mumbo-jumboed" together. Like this, the attacker would have to guess my algorithm instead of a key which will always change(maybe once an hour).

One thing to note, the packets will be a one way road. The clients will send the command and the server will act upon it.

What are your thoughts? Am I wasting my time? Should I just buy an already made board with for alarms with sensors and such? Has anyone done something similar (I know home automation with Pis is a big thing, but I only see little things and I want something bigger, more comfortable).

EDIT: I removed the unnecessary things from the post, as suggested by DannyNiu.

Answer 1

Setup a DTLS proxy that invokes your server program to respond to requests should work. You don't need to put security and functionality in a single monolithic bundle.

This is called the Unix philosophy - write multiple programs that works together instead of trying to solve everything at once.

I don't know about NodeRTC you've mentioned in the comment, but there's another archtypical program called "ssh" we use everyday. At its minimal, it's a program that establishes secure channels between client and server, the channels can carry anything from stdio, tty, x11, to just any data. (which by the way is much easier to setup than a DTLS proxy if you may consider).

SSH saves its configs and keys in local files protected by permissions - had it been encrypted, it can't automatically start itself and would require user to input passphrase.

Since this site is about cryptography, the software part of the question should be kept out or it will be off-topic.