|
Re: Possible FLR Hacking?
Here are a few thoughts
1) I personally would be more likely to look for snowballs in hot places than look for hackers who break WPA2 keys and issue legit commands to teams' robots.
2) It is dead easy for any team to insert their own error detection and correction bits/words into application-level messages that travel to and from their robot. If a hacker was given or stole a WPA2 key and was creating garbled message payloads within otherwise valid messages, the team's custom, application-level detection/correction code would/could record the evidence.
3) It is dead easy for any team to create a 1-time pad cipher that would be shared by the application code in their driver station and their robot. Using one (plus a few other simple tricks) would prevent anyone with intimate knowledge of their robot and of their error detection/correction schemes from sending bogus messages to to the robot (unless they also had a copy of the pad).
4) If you want to implement items 2 & 3 go right ahead, you will learn something. One thing you are almost certain to learn is that your robot communication path is not being hacked. Maybe the path is having messages get lost due to environmental interference or unfortunate radio locations, but I'll risk betting a nice pizza that it isn't being hacked.
5) Have a contest to see who can hack your comms. Offer a pizza in exchange for each new method someone uses to successfully and non-trivially interfere with operating the robot (put it up on blocks for these experiments...). Report your findings to FIRST. Other than by using raw noise to simply overpower the radios, I'll bet few pizzas will be earned.
6) If you do ever think you have detected true malicious interference with robot comms, DON'T BE OBVIOUS about it. Don't grandly announce to your team and to the world that you have solved/discovered "the problem". That rumor will go through the tournament faster than an offer of free Red Bull & Krispy Kremes. Be mature and professional. Double and triple-check your evidence, then discretely contact FIRST and have a quiet conversation to see what they think.
Blake
__________________
Blake Ross, For emailing me, in the verizon.net domain, I am blake
VRC Team Mentor, FTC volunteer, 5th Gear Developer, Husband, Father, Triangle Fraternity Alumnus (ky 76), U Ky BSEE, Tau Beta Pi, Eta Kappa Nu, Kentucky Colonel
Words/phrases  I avoid: basis, mitigate, leveraging, transitioning, impact (instead of affect/effect), facilitate, programmatic, problematic, issue (instead of problem), latency (instead of delay), dependency (instead of prerequisite), connectivity, usage & utilize (instead of use), downed, functionality, functional, power on, descore, alumni (instead of alumnus/alumna), the enterprise, methodology, nomenclature, form factor (instead of size or shape), competency, modality, provided(with), provision(ing), irregardless/irrespective, signage, colorized, pulsating, ideate
|