On Sun, Dec 24, 2023 at 11:59 AM Mark Phillips <m...@phillipsmarketing.biz> wrote:
> I am working on a project and need some security advice. > > The project is a wireless model rocket launcher. It consists of a Raspberry > Pi 2 W (Debian Buster) connected to a daughter board with circuitry > to control the current to ignite the igniter, a TP-Link Wifi AP, and a cell > phone. There is a web site (apache and flask) running on the Pi that allows > the user to control the circuits on the daughter board to launch the > rocket. > > The typical location for launching the rockets is in a large field far from > any buildings or trees. Typically, there is no WiFi Internet connectivity > and cell service is problematical. There are quite a few people attending > the launch. There are also times when this launcher will be used in a more > urban environment (like a high school field), so there may be WiFi and cell > access to the Internet. I want to make the system "unattractive" to the > high school students or anyone else who thinks it would be cool to hack the > launcher during a launch. > > I want to set up some sort of secure connection between the cell phone and > the web site running on the Pi. My main concern is an attacker connecting > to the web site and igniting the rocket while the user is connecting the > wires to the igniter. Model rocket motors generate an exhaust gas with a > temperature of ~3,000 F. Also, the igniter needs 2-4 A dc for 300 - 500 > msec to ignite the rocket motor. > > I have put these security layers in place. > 1. 16 character password to access the WiFi AP network > 2. MAC address filtering on the WiFi AP > This is useless. MAC addresses can be forged easily. > 3. Self signed SSL cert for the web site > This only confirms to the client that they reached an authentic website. And not really, since it is self-signed and there isn't a convenient way of confirming it's valid. It doesn't prevent someone else from accessing the website, only from pretending to be the website. If it were possible to confirm the certificate was valid, then this could theoretically prevent someone from becoming a man-in-the-middle and stealing the credentials that are protecting the secrets in step 4 and 6. > 4. 16 character password to access the web site > 5. Standard flask cookie security for CSRF > 6. 8 character code to enable the launcher (the equivalent to a physical > launch key) > Consider some kind of temporary code, like a TOTP. > 7. A physical switch on the launcher that disables the ignition circuit - > for use when attaching the igniter leads to the rocket engine. However, > there is no guarantee that the user will use this switch everytime he/she > loads a new rocket on the launcher. [...] If this is for a club activity, make sure they DO, EVERYTIME. Put it in the Standard Operating Procedure. I'd suggest something like a physical key switch, where the key necessary to enable the launcher is physically attached to the person designated to attach the igniter wires on a lanyard or something, that can only be enabled by inserting that key from a safe distance. I am not a security guru, so I am not really sure what my options are. Do > you have any other suggestions on how I can make this system more secure? > Am I doing anything that is unnecessary? > Yes: using a website to launch the rocket. -- Russell Senior russ...@personaltelco.net
