The existing system works using Galaxy RS485 peripherals like a "Max Reader". This works, but is there a better way.
Well, WiFi, maybe...
This is a tricky matter to consider. We know WiFi is not as "contained" as wires, meaning more vulnerable to attack and disruption, to say the least.
So, let's consider some pros and cons.
RS485
- Generally very reliable as wires usually are - that said, it has limitations - notably number of devices on the bus (both in terms of physical aspects of RS485, and polling time constraints).
- Hard to access if in the walls, inside the building, but things like Max Readers expose the bus externally (albeit at cost of tripping tamper).
- With any access (e.g. Max Reader) very easy to disrupt (albeit with tripping tamper).
- Very insecure - I have done a proof of concept with access to the bus that can inject messages to open doors, etc, without the slightest hint of a tamper alert from the Galaxy panel.
- Slow
- Needs wiring back to the panel.
- Vulnerable to snooping if you get physical access to bus
- Hard to do redundancy
WiFi
- Vulnerable to RF level attacks (albeit tripping tamper)
- Vulnerable to protocol level disruption (if you get in to WiFi) such as WiFi disconnects or IP flooding or TSP RST flooding.
- Secure if using TLS. Cannot be snooped or faked.
- Fast
- No need to wire back to the panel
- Easy to add a lot of devices (subject to access points that allow lots of associations)
- Harder to do battery backup, but possible - need 12V access points - can be done.
- Possible to do multiple AP fallback and redundancy
So I am making my SolarSystem GitHub project handle WiFi connected devices as an option.
- ESP8266 code for modules
- PCB layouts for modules
- 3D printed cases for modules
- TLS MQTT over WiFi with certificate pinning and checking
- SolarSystem code allows mix and match of RS485 and WiFi connected modules
Not finished yet, but most of the device code in place. I even have a way to use a Galaxy keypad on WiFi!
The door control logic is a relay board with NFC reader, and I am working on proper AES secured cards. The 125kHz proxy cards are stupidly easy to copy!
Whilst it sounds like a good idea, I think you have missed the most important thing off the WiFi list - "Trivially easy to jam". I'm assuming you're building a ping type "are you still there and do we have working WiFi?" check into your code for WiFi connected sensors, but even so, this, to me, is the biggest fear factor.
ReplyDeleteThat was the first thing on my list! And yes, MQTT level pings and reporting fault/tamper if it loses contact.
DeleteWhat about something like Zigbee as an alternative to WiFi? It's lower power (so your battery can last longer) and lower bandwidth (which should be fine unless you're streaming video)
ReplyDeleteJust that WiFi is really easy with the ESP8266.
DeleteI've not worked with many commercial units (Mostly a big projects running cat5 drops to a bunch of doors), but the ones I have cache authorised cards locally, hence connectivity to the backend is not actually mission critical. Have you considered that sort option?
ReplyDeleteI have built in a setting allowing an override card for when wifi/mqtt not connected, yes.
DeleteRather than using 12V access points can you supply power via POE instead?
ReplyDeleteYou could boost the 12V and use something like https://uk.rs-online.com/web/p/poe-injectors/7653364/ to then power the access point. It would give you a better range of compatible access points that way.