but using WiFi mesh networking instead of lora

so I know for a fact we can use WiFi-Direct for a lot of this as it’s one of the things we regularly test at work. problem is the range is much shorter and that matters real fast when you’re surrounded by buildings.

The idea was to build handsets using esp32 modules with external antennas, and build out a huge city wide mesh network working on wifi bands based on small, local repeaters (also ESP based). Esp32 since you can encrypt the onboard flash, they’re pretty powerful and decently cheap.

we actually explored doing this a couple of years ago as well. main issue came down to not having a suitable hub for a backhaul to the internet from which we could expand the network. we’re better situated now and might pick this up at some point.

Since your threat model here includes the most enthusiastic spy agency of any nation-state, I would be EXTREMELY careful about the firmware flashed onto the phones.

I mean more make a ROM myself to kill the wireless capabilities on the device, then ensure it’s done through mechanical damage to the antenna. this gets us as close as we can feasibly get to airgapped and our primary mode of attack becomes the radios themselves. we can’t solve the trusting trust problem, obviously, but we can do enough to make it so that the people using these have to be explicitly targeted by the NSA, using techniques we’ve only theorized to exist – I’m ok with that for a prototype. with more time, there’s a lot we can do to make the underlying network safer by, for example, abandoning tcp/ip (it assumes you can trust the network under you) for more suitable alternatives – these can’t compete with the maturity of tcp/ip, so any implementation time is going to be massive here. and there’s a bunch of stuff like that.

maybe using a linux ROM on android would be good enough

yeah, this is definitely one of the things I want to try. we’re also considering not starting with phones and instead working up from like beagle boards or something but I think the form factor becomes too unwieldy, unfortunately. we’ll see, though – depends on how testing goes.

but I’d say the preferable and way more labor intensive option would be to build your application specifically for your hardware, and only using open source packages

yeah, of course. the part I can’t do too much about are the firmware blobs to run the various hardware components on basically every android phone (really… it’s virtually every piece of hardware you might conceivably use for this…). one of the advantages here, though, is that these devices never, ever touch the internet and the goal is to kill all the radios but the one we’re attaching (a radio that’s fully open hardware, open software, etc.). so there are only two modes of attack – try and get on the network and then spoof one of the other identities, a mode of attack that’s actually well covered by signal’s double ratchet/libolm, or to get physical control of one of the devices. we have some thoughts on how to protect against this last mode of attack but this is an area where we’re going to be trying things and right now I’m leaning towards “wipe the device at the first sign of intrusion”.

Maybe using a pi would be a good idea, since the radio can communicate over both serial and usb? Or if you can manage to shave the code down enough, you could try to run it directly off of another microcontroller.

yeah, definitely considering this. the main worry here is that the device is difficult to actually use in practice because people are very used to phones. remember that one of the goals is to get people to stop bringing their phones to anything even mildly spicy and to use these instead to talk to their comrades, instead (and we really are focused on that mode right now – I’m not putting together any plans right now for trying to authenticate and validate communication between unknown parties for the forseeable future… the plan right now is to force everyone into the same room together to generate and cross sign keys, and that will be the only way on to these things.) the usage model is already going to be strange for people and people working in a mode they don’t understand, taking shortcuts, or just bypassing security features altogether is a much more likely cause for compromise than anything else we’re discussing. that said, this was also my first thought when I sat down to try and put together a plan for this project and something much more custom is very likely if we make it to a second round of development (right now we really just need to prove to ourselves and others that this is viable in the first place, with the caveats of what this can’t protect you from up front and center).

and yeah, I’m super excited about this and I’d love to talk more. I’m @therivercass:matrix.org, hit me up.