-
Notifications
You must be signed in to change notification settings - Fork 16.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
3DR Radio: wireless encryption #1610
Comments
right now the best bet is to use one of the RFD900 varients that has hardware AES encryption. |
Since 900 MHz is a NONO in Europe and the RFD900 guys do not seem to have interest in developing a 433 or 868 MHz version i only see using a RPI and WLAN as a quick goal for secure, encrypted transmission. |
now available: http://store.rfdesign.com.au/rfd-868-modem/ |
@davidbuzz maybe you know what "software still in development for this" means in the product description page? Has anyone tested the encryption feature on RFD 868+? |
It's open source, and the code is available, and looking at the history of the commits, there appears to have been AES references in parts of the code from as far back as 2 years ago. Maybe you should ask the manufacturer directly..? https://github.com/RFDesign/SiK/tree/SiK/Firmware/radio/AES |
Yup, did it already, just thought someone actually used it. |
My comment comes 2 years after the last post on this page. RFD-868 seems to be 4 years old now in development, I saw some AES encryption seems to be part of the firmware but no update on it in releases or documentation page. The last commit is also more than a year ago, makes me wonder if this project is still active? This however is the closest I could get to a state-of-the-art device that enables long range + encryption. Anyone any idea about long range >1km with encryption for EU? @naktinis , @davidbuzz, @robustini, @tridge ? |
AFAIK The SiK firmware provides AES encription (for the 3DR modems), but you need to compile it from source because no official releases have it. @tridge correct me if I am wrong. |
@amilcarlucas Thanks for the update. Have you tried using it on the standard 3DR modems, can they handle the encryption part? It makes me imagine encryption/decryption could be too heavy on the 3DR radios resulting in packet loss/lower practical baud-rate. Any views on this? I might be mistaken. PS: Do you mean the original SIK firmware as written by Tridge (https://github.com/ArduPilot/SiK) OR the one I mentioned (https://github.com/RFDesign/SiK) by RF Design? Both have AES [SiK/Firmware/radio/AES/] |
This wasn't mentioned in this thread so I'll state it: ArduPilot itself has no encryption but the MAVLink 2.0 protocol used by ArduPilot can use SHA256 signing and that is passed over the 3DR radioes or anythign else using a serial port. So, it's not "encrypted" but it's close. This was implemented about 1.5 years ago. I suggest giving it a try. |
@magicrub Thanks for sharing, and yes I am aware of signing implementation and also have read the Google docs document here (https://docs.google.com/document/d/1ETle6qQRcaNWAmpG2wz0oOpFKSF_bcTmYMQvtTGI8ns/). However, it might be easier for me to use an encrypted link (if feasible) as its for a product and signing could be hard to debug in case we fall into some packet loss issue (e.g. due to timestamp mismatch in the signing algorithm). |
Also, I found that there are two versions of RFD868 or RFD900 radios: ending with "+" OR "x" AFAIK there is no easy way to encrypt the data link on the RFD868+, only the RFD868x has the built in AES encryption hardware. Without that you would need to encrypt the data stream that is being sent to the radio, the radio won't do the encryption for you. |
Closing this as the radio encryption isn't related to ArduPilot. Also, for discussions like this please use the forum (http://discuss.ardupilot.org). |
This is the repo that hold the SiK firmware: https://github.com/ArduPilot/SiK but this is a bit more of a discussion item |
We have discussed many times, in my country (Italy) and in many others in Europe we could not use APM Copter or Plane in critical restricted operations because the 3DR telemetry has no encryption level.
This unfortunately is castrating and company will push many to adopt other systems where this thing is doable.
I hope Tridge or Kevin can quickly find a solution to the problem or here the market of our drones inevitably will move to other platforms where this system exists (DJI for example).
The text was updated successfully, but these errors were encountered: