why would encryption even be needed? who’s doing MITM attacks on RC remotes?
But Mr. Jenkins, what if I first record the data the remote sends when braking, and then replay that data from my transmitter to attack my victim? (Replay attack) We need to also include a forever incrementing counter in the data being sent so that we can differentiate between old and new data 
3 Likes
God… This is why I’m not a security professional…
The incrementing counter is a good idea.
3 Likes
Whoa…good point!
I’m with @dasman, the depth of knowledge you need to do security stuff well is daunting.
2 Likes
Yeah I’m informed enough to know when I need to stop and find something a professional out together.
1 Like
I definitely agree that we are only concerned with identity of the packet sender and integrity of the packet and don’t care about hiding the data.
Actually now that you mention digitally signing the packets that would be a far more elegant solution and you could exchange public keys during binding. However digitally signing is normally done with RSA which is more computationally expensive than symmetric encryption. So maybe symmetric digital signing? Will still need to exchange the key somehow.
I would say that the chance a remote is a target for one of these attacks is going to be very rare, however the consequences could be quite bad (losing control of your board in traffic) compared to regular RC. So implementing methods to mitigate them should be considered. However if we are limited by hardware then its probably fine not to implement and just be aware.
A lot of attacks are possible and its unlikely that all will be covered. Though every little bit improves the remote.
2 Likes
What are your thoughts on the reliable packets as explained here.
Examples 207 and 208 look pretty interesting. Adds error checking which is great. The identity is done in a very similar manner to how @thunkar already has it implemented, but to be able to hand off the responsibility to the library would be a bonus.
I believe the reliable packets in those examples could be implemented pretty easily. So this is a good find.
They won’t handle purposely malicious data though.
From what I understand people are worried about encryption because a directed attack to the reciever would be pretty catastrophic for the rider.
I suppose that the remote being open source, brings more Risk to the situation as the attacker has all the info needed for a successful attack.
In my opinion, the chances of a directed attack are extremely small, and, in my case not even worth the work (i don’t have enemies, good vibes only 
).
But in case someone it’s worried about that i would implement the simplest encryption possible, and just manually load your own encryption key through the computer.
I really don’t know much about this but using resources that would shorten battery life and maybe reliability doesn’t seem worth it to me and probably to the general public.
Maybe I’m not making sense and packet encryption it’s standart practice on an Esk8 remote, please instruct me!
2 Likes
You only need one person pissed off enough sitting on a bench next to the road waiting for you. Here is one example exploiting Exway boards.
Some kind of protection is absolutely worth implementing and I’m gonna look at the CRC integrated by the library ASAP.
But don’t forget that in the end someone could just blast you with noise @ 2.4GHz using a helical antenna and some inexpensive hardware and leave you with 0 control over your board. It’s exactly what those “anti-drone” cannons do.
8 Likes
The crc is only a difference of the send and receive methods called.
There is a crypto library that can do sha hashing with hmac on Arduino
seems like a lot of unnecessary overhead when one could just bail off the skateboard to avoid death.
as people have said, the chances of a directed attack are going to be extremely rare, and there’s no defense against indirect noise attacks.
why not use the computing power for something more relevant to control?
Has even anyone ever in the last 5 years get “attacked”?
I do get the concern but how likely is it that someone is waiting for an esk8er to pass so he can send some signals back to hurt the rider.
1 Like
I think a small amount of overhead could probably be justified.
“Just bailing off the skateboard” is in no way any guarantee of safety, but especially so in traffic.
So, you’re saying there is a chance. I agree there is a chance of a directed attack.
With all due respect, what is more relevant to control than unfettered command over the vehicle’s control inputs?
there is also a chance of land-sharks evolving within the next year.
2 Likes
tHeRe iS aLsO a ChAncE wE gEt hIt bY a MeTeOr
jokes aside, having secure packets seems reasonable, might as well prevent what we can if it’s not too hard to implement
2 Likes
this is the caveat. if it taxes computational resources enough to impede control at all it becomes more of a hindrance than a feature.
1 Like
While I agree that the the chances are slim.
Some sort of digital signature also ensures that another remote nearby running on the same channel doesn’t cause interference.
4 Likes
That’s actually covered at the moment by the remote’s ID. Using the library’s built-in mechanism is just a more convenient way to do it plus the CRC adds an integrity check to the package (and that’s always good and not that expensive).
I think ATM that’s gonna be the way to go. If someone is able to identify the channel you’re transmitting on even though the protocol is VERY wideband (due to the spread spectrum modulation), sets up a LoRa sniffer, decodes the package, gets your remote ID and blasts you with a powerful enough signal to overwhelm your receiver…holy shit, you probably did something terrible to them. I don’t think any remote in existence is protected against such a dedicated attack.
11 Likes