@Greg: awesome to hear about the TWOG!
I still have several Tiny13 I keep sealed so one day I can fly with it. Still today I stare at it in wonder as it has GPS onboard with power, with the processor, with molex... If only it had a single chip IMU and baro (hint), maybe stm32f4? It could be still the smallest ready to integrate controller. All the designs are wonderful and open.
Point really is how thoughtful the Paparazzi group is to not obsolete past hardware and why separation of business from development is so good for the community.
Security for Linux based, open source Drones, will evolve quickly thanks to the open nature of the platform. I now admire Parrot for giving us something unlocked so the community can make it as safe as we wish. Some have already said they are OK with no security. Others wish more.
I am happy to share what I continue to learn so stay tuned.
On Aug 26, 2015 1:16 AM, "Greg Jones" <
address@hidden> wrote:
It's been a few years since I last posted I know but I'm still reading the list!
Surely the elephant in the room here is not so much how to secure Linux, this itself is well documented, the problem is the potential to remotely force Paparazzi to switch flight modes by abusing the RC receiver and moving from AUTO2 to AUTO1 or MANUAL.
A remote attacker need only transmit a value on the necessary RC channel, there is currently no security on this mechanism and this mode switch is all that is needed for the remote attacker to take control of the UAV.
The benefits of.having the RC override have undeniable safety benefits and I wouldn't fly without it but it is a major vulnerability, for me the most major vulnerability.
I do not attach any security value to the anti-interference controls in PCM based receivers to prevent spoofed signals and even if they were enhanced, short of some properly implemented cryptographic authentication between RC transmitter and RC controller, they can be readily defeated using a cheap SDR.
Anyway, so ends this decades post for me.
And Mr Conger, that TWOG I got off you 6 years ago is still going strong!
Best
Greg
________________________________________
From: paparazzi-devel-bounces+greg.jones=address@hidden [paparazzi-devel-bounces+greg.jones=address@hidden] on behalf of Jan Čapek [address@hidden]
Sent: 25 August 2015 10:07
To: address@hidden
Subject: Re: [Paparazzi-devel] Securing the Paparazzi drone
Excellent summary, our company has years of experience in running and
securing Linux based systems (including embedded targets, too). However,
we are quite new to the UAV platforms. World is full of naive solutions
with none to zero security. People using toys don't seem to care about
this too much. However, commercial and industrial use of UAV's calls
for a certified software which will cover security aspects too. This is
an area that we want to focus on once we gain enough practical
experience with UAV's.
Best regards,
Jan
Dne Mon, 24 Aug 2015 16:08:40 -0400
David Conger <address@hidden> napsal(a):
> I have mentioned security in the past. I remember making an ARDrone
> fall from the sky in a part in Toulouse from my iPhone as a
> demonstration these drones are too insecure...sorry guys for that I
> made sure it was only a few feet from the grass before pressing enter
> :]
> Three years later at BlackHat a much more public demonstration of the
> same got a lot of attention. I was surprised this gaping security hole
> still exists. Open root access to a flying robot???
> I propose a simple fix I do all the time to any Linux system I work
> with: 1. exchange ssh keys
> 2. disable password login completely for every account
> 3. disable root login, do not use root at all (sudo) and monitor root
> access of any kind
> Has anyone considered simply exchanging id_rsa.pub files, disable
> password login, the simple things are often the best. For any server I
> manage there are no password logins or root logins allowed ever. They
> key can be generated somewhere else and if the right files are
> exchanged it works fine. cfengine can easily mass setup systems (read
> drones at the factory) with security in place before shipping to
> eliminate sending them out all open to the world for root. So easy to
> do pls consider it vendors.
> Paparazzi is not nearly as insecure from ENAC. Smart minds enabled a
> HASH "key" exchanged at compile so the drone refuses messages without
> the proper key. Now however we are running Paparazzi on less secure
> platforms so it is time to address security again.
>
> As Parrot uses Linux and it should be trivial to implement ssh key
> exchanges at the factory using automation (cfengine is nice). I have
> setup cfengine scripts to build entire Oracle RAC clusters from bare
> metal so I know what goes on the ARDrone is easily doable this way.
>
> Initial drone security (also Skycontroller) would be the 3 steps
> given. Now with keys in place your programmers on the ground can
> interact with the drone without sending any passwords over the air and
> with sudo all steps required can be done, safely.
>
> Is there anyone with questions? If so just ask I'm glad to help. I
> have already seen one video where someone uses aircrack-ng to send a
> WiFi deauth packet then connects and takes over control of the drone
> using automated scripts from a flying Raspberry Pi with Wifi. Trivial
> to do really but sadly it's so trivial to do. Let's fix this together!
>
> -David
>
> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
--
Braiins Systems
tel: +420 604 566 382
email: address@hidden
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel