Hi,
is there any encryption and/or authentication on the air interface of the 3RD radios? As I understand, XBees run AES-128 on the airlink.
-S
You need to be a member of diydrones to add comments!
This reply was deleted.
Hi,
is there any encryption and/or authentication on the air interface of the 3RD radios? As I understand, XBees run AES-128 on the airlink.
-S
You need to be a member of diydrones to add comments!
Replies
Isn't the elephant in the room here, the question of how to protect the RC Control link? To me, it seems fairly limited what a person could do to an APM with the telemetry link. Maybe they could make it crash. I suppose they could alter the mission, only until I flipped the RC control back to stabilize.
It's that RC link which is key. What is the status of that? If that is vulnerable, so is every other RC model.
And then, that was always the case. Back only 10 years ago, if you wanted to crash, or maybe even take over somebody's aircraft, all you had to do was turn on your 72MHz radio on the same channel...
John, about security, you got my point. In most countries, the owner is responsible for a UAV. So the image of some bored kiddo buying himself a 3dr radio and taking over my bird doesn't amuse me. Besides the obvious risk of damage, there is the risk of misuse which will also come back to you. And proving, not you flew the bird but somebody took it over, might be not so easy. Even in the simplest of all cases - simple theft - the (financial) damage can be substantial.
XBee is indeed encrypted with 128 bit AES - according to Digi's data sheets, that is.
I agree that implementing the encryption into APM is the wrong way, because that would mean that on the other side, the encryption must be integrated into the GCS, which makes things a hell of a lot more complicated for developers plus the performance issues, Marijn talked about.
I started this discussion intentionally with the title "encryption in 3DR radios", because I think, ideally, encryption should be on the RF-side - completely transparent to the applications. That allows for high performance, flexibility and also some "investment protection" for the future, as when AES-128 gets broken or new algorithms surface, not the APM and the GCS have to be redesigned but simply the radio firmware has to be updated or new modules have to be used.
Additionally, bearing US export restrictions in mind, encryption on the RF-interface would not restrict export of the APM and GCS but only of radio modules with strong encryption. So, there could be an "international" version with e.g. AES-128 and a US-version with whatever stronger encryption. Encryption in the application side COULD open an ugly can of worms...
I am using XRF Ciseco for my telemetry with APM. It is 100% compatible Mavlink.
On the link below there is mentioned: "Supports 128bit AES encryption like all the other devices do."
I would believe 3DR or XBee should be also encrypted, since the statement is "like all the other devices do".
XRF Ciseco
Security to prevent someone actively trying to hack the system, just turns into a cat and mouse game and is far outside the scope of a DIY hobby system like ours. Basic authentication and/or unique ID for each transmitter/receiver to prevent accidental conflicts should be more then enough for our needs. Anything else just means a lot of work and more that can go wrong, with no real gain. Always remember to KISS.
I got three thoughts on this matter.
1. Encryption is probably required, just authentication won't cut it. You can simply inject your own data into an already authenticated connection and send commands to the drone. This might be made difficult with channel hopping etc, but I assume this hack to be possible.
2. Encryption takes time, I believe the ATMEGA2560 is pretty much fully loaded at the moment. Where will we find the processing power to run encryption/decryption? (I haven't run any tests/calculations on this, so it might not be a problem at all. the encryption phase might be so short it does not cause a significant slowdown on the cpu, but I doubt it.) Maybe the radio itself can run the encryption? Or a new hardware device can be added between the apm and the radio.
3. Authentication can be implemented completely transparently using asymmetric encryption. This would function as follows:
- The APM is connected to the Mission Planner via USB.
- The Mission Planner generates a private key and the corresponding public key.
- The Mission Planner uploads the public key to the APM, which stores it on dataflash. The private key is kept secret.
- When a radio connection is established the APM uses the public key to send a symmetric encryption key to the mission planner. The mission planner can decrypt this symmetric key with the private key. This symmetric key is then used for all data encryption
With this implementation of assymetric encryption, the user won't be faced with complex encryption setup, it will simply setup automatically once USB is connected.
I don't thing, there will be encryption for consumer R/C controllers anytime soon, because - well - they are consumer products and R/C vehicles are usually controlled in line of sight.
A drone, especially, a UAV is something quite different, IMHO, and does warrant enhanced security.
at least no authentication, nor any encryption I know of.
AFAIK - the few ID bits are the only method of separating links.
-
1
-
2
of 2 Next