Schneier on Security
A blog covering security and security technology.
« Hacking Faxes |
| The Problem with Electronic Voting Machines »
November 9, 2004
Peer-to-Peer Alarm Systems
Here's an alarm system that calls out to other similar systems within 150 meters. Interesting application of the peer-to-peer philosophy to physical alarms.
Posted on November 9, 2004 at 11:03 AM
• 10 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
That's a pretty sweet idea. It gives people a piece of mine.
quoted from the article: "If there are 19 or 20 out there, if one person pressed the alarm button, then there are 19 possible people to respond."
Interestingly no mention of how many "actual" people "would" respond.
Real Scenario1: You hear your power ranger alert saying unit 13 is sending alarm, and you figure... ah I'm sure units 1-12 will go check it out... all the while 1-12 are saying the same thing you are... now that is reality.
Real Scenario2:Even better yet if one of the criminals is 1-12 then they can throw a rock into 13, and whilst all of 1-12 is investigating the alert, the very same 1-12 are being broken into...
Lastly, it is the very "piece of mind" that induces vulnerabilities due to "false hope".
I don't mean to sound cynical, but the MCI Friends & Family marketing plan comes immediately to mind. Why advertise your product, when you can get customers to market it for you?
It's a nice idea, but it's just asking for mis-use. Am I the only one who can see the similarities in this device and the "Boy Who Cried Wolf"? I mean, if you're feeling bored or lonely one day, what's to stop you pushing the panic button to get a few people over to your house?
Israel's point on the *actual* number of respondents is very good. "The Tipping Point" by Malcolm Gladwell (www.gladwell.com) discusses some psychology research in this space, which shows that the number of observers is key to how people respond to an apparent crisis. When smoke comes under a door in a room with one person they always respond; in a room with several people there is often no response from anyone. The "if it was a problem then someone else will have dealt with it" approach kicks in, and everyone treats it as a lower priority.
Just think how you respond when you hear a house alarm or car alarm ...
On a side track, how about when an elderly person sets off the alarm because of a safety problem. Can anyone see the scenario of all 19 neighbours being elderly too?!?
This comment is quite off-topic but may be interesting to those who are looking for other avenues of P2P applications.
Some guys out in California talked about a similar concept with firewalls and IPS systems. I believe they called it the "friend system". Each IPS passes it's newly made configuration changes to it's friends - other pre-designated IPS - which have the choice to accept or reject those changes.
It is important to analyze the effects of this particularly with regards to embedded applications making their way into our houses. How will they communicate with each other and keep their defenses up? Will Dad always be the CSO of the house configuring and maintaining firewalls and IDS/ IPS systems?
May help analyze this situation as well :)
Most home security systems notify a central monitoring system via telephone if an alarm is raised. The monitoring facility can then send a security agent to investigate or notify police. An intruder can trivially defeat the alarm notification by cutting the exterior telephone cable before attempting entry. Systems equipped with RF "buddy system" feature can request that a nearby system contact the monitoring facility by proxy. Home security systems have had this functionality for at least 10, maybe 20 years, though relatively few installations employ it.
On the subject of the number of responses; surely part of the solution might be for all the alarm units to also show how many people have responded (this would need to be declared by someone hitting a button as they go out to respond). That way there's a positive indication that someone has dealt with the issue, which is something missing from the existing alarm systems (at least in my neighbourhood).
This idea although sounding good is infact quite bad, it will if widely implemented prevent better systems without this ones inherent faults being deployed.
Several people have pointed out the "Cry Wolf" aspect but have only attributed it to a valid but lonely user of the system, not an outsider with hostil intent.
Imagine that you want to break the system for some reason the easiest way is to make a unit that sends out spurious signals or jams real ones. The result is that people will quickly lose faith in the system and will stop using it
at this point it is a waste of resources. Also the word will quickly spread about the "unreliability of the system" and all similar units will get tainted with the same view.
To prevent a rouge unit being introduced into a "net" of units requires carefully thought out protocols. Likewise detecting jaming signals requires a carefully thought out aproach. I suspect that neither of these has been taken into consideration in the design process.
To be effective both aspects need to be considered at the same time, people with the experiance of designing these systems are not exactly thick on the ground, and I suspect that their talents are being deployed in other (related) areas.
For an idea of what might be required have a look at Ross J. Andersons home page and a link of to a paper (Key Infection) he co-authored on a closely related subject,
I have one of these. If an intruder trespasses into my yard, my perimeter monitoring system sounds an audible cycling alarm. If the alarm sounds long enough, similar alarm systems, not even of the same model or manufacturer, will add their audible signals to that of mine.
If, for some reason I am unable to investigate the cause of the alarm, it is very likely that a neighbor will come outside and yell,"Will you bloody dogs shut up?"
Schneier.com is a personal website. Opinions expressed are not necessarily those of BT.