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
Interesting discussion! Makes me wonder 4 years post the last comment, what has been the conclusion in terms of encryption on low-cost radios? Do we already have it, or yet pondering on a genius idea to make it happen, coz even Google is unable to answer this query to me.
how to hijack a drone over telemetry , and prevent it;
http://madhacker.org/?p=13
Why is the post by Michael Zietlow deleated ?
And does anyone take the huge security flaw/lack seriously ?
There seems to be some confusion here.
Encryption, correctly implemented, prevents someone from comprehending the contents of the messages being sent.
Authentication, correctly implemented, allows the recipient to trust that the sender actually sent the message that was received.
It is common to mix the two; after an initial exchange that establishes authenticity, knowledge of the encryption key by the sender is treated as authentication by the recipient. However, this glosses over the initial exchange, and it also omits any protection against replay of a previously-authentic message (or suppression of authentic messages) by an attacker.
The 3DR radios don't have the computational resources to implement a sufficiently secure link; they are basically tapped out with their current functionality. Building a secure link is going to require a new (and more expensive) hardware platform.
Can we please use a separate topic for encryption of video links? This is about the 3DR-radios. Thanks!
Some stuff to read...
http://rf.harris.com/media/Acropolis_tcm26-9013.pdf
http://www.altera.com/products/ip/ampp/dcrypt/dcrypt.html
http://www.maximintegrated.com/datasheet/index.mvp/id/6479?utm_expi...
there is no denying, we need encryption.
It would take a lot to prove that a bad situation was *not* caused by the pilot, who, after all - is responsible.
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...
-
1
-
2
of 2 Next