First off, kudos to the author, awesome project and a very nice read.
During the first round of lockdowns I also spent a few lazy afternoons tinkering around this idea, mostly to get the feeling of how hard it would be (https://github.com/carlosefr/pialarm).
There are a few nasty requirements commercial alarm systems have to meet that I don't see mentioned in the article, namely how it protects against tampering and voltage spikes (which can be used as a form of tampering).
One way to protect the controller from ESD and shorts is to use optoisolators on every input and output, which should also be dry contacts (grounded=on, floating=off) whenever possible.
To detect environmental faults and tamper-inducing faults the controller can use analog inputs (which the Raspberry Pi doesn't have, but can be easily added with an MCP3008 ADC, for example) instead of digital GPIOs. This is why commercial systems need input resistors inputs added at install time depending on the particular sensor configuration.
As a software person, thinking about these things gives me a much greater appreciation for people doing industrial electronics design.
PS: For the average geek, an easier path is to interface a Raspberry Pi to a "dumb" commercial alarm. You can have the Raspberry Pi behave like a standard sensor input or monitor the sounder outputs.
There is no protection against voltage spikes on the inputs, there is just the pull-up resistor on the Raspberry Pi input. So this is a weak point. I did consider both EOL resistors and optoisolators when I first got started. But decided against it.
There are dedicated tamper inputs, which runs through the tamper switches in multiple devices before returning to the control cabinet. But EOL resistors would be a better and more secure option. I have thought about using something like an AVR microcontroller to read the voltage level and convert to something the Raspberry Pi could use. Maybe in the future.
I can always make changes in the future — thanks for your input :)
Another weak point I've thought of, which probably applies to many alarm panels with zero knowledge of the correct pin, is what safeguards are there preventing someone from doing replay attacks on the pin entry? I would think a hardlined panel would be more secure.
I agree. The ZigBee protocol is encrypted, but a replay attack is probably still possible. Another advantage of a hard wired panel is that it's not dependent on the Zigbee network being operational, and could be operated on the backup battery for days.
I think many systems fall through if the threat model includes someone watching you and doing a replay attack. But I'd still prefer a hardwired panel TBD. It's just not very easy to retrofit, with hidden cables.
During the first round of lockdowns I also spent a few lazy afternoons tinkering around this idea, mostly to get the feeling of how hard it would be (https://github.com/carlosefr/pialarm).
There are a few nasty requirements commercial alarm systems have to meet that I don't see mentioned in the article, namely how it protects against tampering and voltage spikes (which can be used as a form of tampering).
One way to protect the controller from ESD and shorts is to use optoisolators on every input and output, which should also be dry contacts (grounded=on, floating=off) whenever possible.
To detect environmental faults and tamper-inducing faults the controller can use analog inputs (which the Raspberry Pi doesn't have, but can be easily added with an MCP3008 ADC, for example) instead of digital GPIOs. This is why commercial systems need input resistors inputs added at install time depending on the particular sensor configuration.
As a software person, thinking about these things gives me a much greater appreciation for people doing industrial electronics design.
PS: For the average geek, an easier path is to interface a Raspberry Pi to a "dumb" commercial alarm. You can have the Raspberry Pi behave like a standard sensor input or monitor the sounder outputs.