As I have posted, I have had some fun making a new alarm panel. There are higher levels still to do, and I am sure many features will be added as it is used in anger. I have it at home now, and office will follow later. I am even making a system for the climbing frame/swing thing in the garden as a bit of an alpha test platform.It was started as both a bit of fun and out of necessity. The necessity is that we have a number of small niggles with the Honeywell Galaxy systems we have here and at the office (see below). One way to address some of these would be to get an new alarm installer and maintenance company - but I am confident that it would (a) not solve all the niggles, (b) cost a lot to solve those that can be, and (c) cause more problems as we would mean calling them if we have to reset the alarm for any reason. So, yes, making my own alarm panel is not as daft as it sounds, especially as I have the skills to do that. Reinventing the wheel is one of my specialties!
Having spent a couple of weeks making some code, and making prototypes, and a working system - I now have a nice solution.
Will it monetise?
As a businessman I have to consider if we can now make money out of this. Right now it is A&A copyright, and A&A has paid for my time and the various bits of kit to develop it all. The company deserves something, either money, or customer acquiring kudos. A&A will get a new and better alarm system, which is a start!
It is tricky. I expect that most can be made selling, installing, and maintaining the actual systems for people. Retrofitting where a Galaxy panel exists for example, selling a system review, and selling maintenance and monitoring. Now, A&A have done telephone system installation in the past, on a small scale, but we are really not geared up for "field engineers" for installation or maintenance, to be honest.
So could I just sell the system - well maybe, but ultimately it is just s/w, and that is not that easy to police and sell. We could make physical systems, a panel box with RIO PSU and Pi and the RS485 leads, all neatly put together - maybe. We could resell the alarm system parts even? It also creates some possible liability issues - what if someone is robbed because of my code having a bug? And then we would need to establish dealers and relationships with those companies that do in fact do installation and maintenance and so on. These are all, for now, well out of our comfort zone as a company.
So, to be honest, I am not convinced I can make a lot out of it, yet...
Should I open source?
Well, this is, in part unrelated to the above. It is possible to publish source and have restrictions on use. It is possible to have some controls. It is actually quite hard to avoid and police pirate copies even if not publishing source. It is also quite possible to make and sell systems that are built on free open source software. Publishing the source code is a good thing to do, and if we are unlikely to make no money from it, that helps make it a no brainer. Or does it?
Vulnerabilities?
I may have vulnerabilities in my code that I have not spotted!. If published, someone could find them and exploit them to rob us, or other people. Of course, they don't know if we have any backup systems to alert us anyway - some part of the old alarm panel still running just for alarm/security and not the problematic door control issues... It would be a risk to try and exploit such issues. I also have slightly more faith in humanity and would expect someone to tell us if they saw an issue in the code, or at least not bother to exploit it, or at least not have the contacts to let someone else exploit it. So maybe safe to publish anyway.
Who controls the "official" version?
It always helps if there is an "official" version, and if we ever get it to meet security specs or British Standards that also helps confirm which versions does that. But who controls it? There are many ways to release code from just putting it out there, to putting on a community repository, to accepting code updates, or suggestions, or changes, and simply controlling the master copy ourselves.
If anyone can submit new code, or make changes, one has to be careful. It would be easy to hide a deliberate vulnerability or introduce a accidental one.
I was pondering, for example, I have key fob codes (numbers) and zero is invalid. If someone just removed the if(e->fob) line from the code that does nothing with a zero, then zero would be valid and may match any user without a key fob defined as they have zero stored - thus allowing a crafted key fob with zero ID to work to unlock and enter. But they could be a lot more subtle - e.g. if the key fob codes have a check digit (I assume not, but I don't know) someone could replace with if(keyfob_valid(e->fob)) and code that function to check the check digit but carefully so that an all zero fob will pass. That would look like a good and valid enhancement, and the loophole for zero would be subtly hidden. Just one idea of ways to hack the code with only a few minutes thought.
Go for it!
Let's assume we do want to make it open source, what is the best platform? Ideally where I have control of at least the main parts of the code in the "official" version. I have not done this for a while, so interested to hear.
I released some L2TP code for linux many years ago and apparently now it is some big and sophisticated system that some ISPs actually use! Totally unrecognisable to me, with loads of new features. Still has my name, which is nice.
I issued some SMS code for Asterisk once, and asterisk has changed and so has my code. Asterisk have an interesting community code copyright model. Apparently it has changed to the point it stopped working, and nobody was interested in fixing it (not even me, now). I coded something from scratch for when I needed it recently, outside asterisk framework (SIP, and alaw RTP).
We have published code on the A&A web site, and people use that with rarely a suggestion or bug report, but I know some is used by lots of people just from some of the feedback I have had (the linux drivers for Epilog laser engraver, for example).
To some extent it depends how good, and complete, my code is, which is partly why I have delayed releasing so far (I do not think complete enough, yet). If I have done it right people will use it and have hardly any suggestions or bug reports.
Open source code also benefits from the usual disclaimer of no fitness for any purpose nor liability for bugs. That is a good start. I am happy with our normal "money back guarantee" on stuff we provide for free, and I think it is more than fair :-)
The code is also layered, so a good chance the low level will just work and the higher levers will have lots of ideas and suggestions and changes, so it may even be appropriate to publish different layers using different publication models.
Indeed, one model may be open source the components but make a "system" with the web based config and status that is not open source and looks nice, and we sell that as a solution (with usually open source disclaimers?).
Do say what platform we should use to open source this...
P.S. Some of the niggles with the galaxy system and how I have addressed them - how many of these would be addressed by getting in a "proper installer/maintainer" I wonder?
- You hold the fob 3 seconds to arm/set the system, but actually it is implemented such that you can use fob, and then use fob again in 3 seconds, so two separate uses can mean arming by mistake. New system expects actual hold for N seconds.
- Once set you use the fob to unset, but then have to use again to open the door. Be careful not to be 3 seconds apart doing that. New system unsets and opens door in one go but does beeps to confirm unset.
- The doors seem to have a lag at the office. New system allows 4 buses per Pi so can minimise lag. It also allows a lot of debug to find underlying issues on buses.
- If you have a door with a mag lock at the top and reed switch at the side (even at the top by the mag lock in one case at the office), pulling the door whilst locked will trip the door forced alarm. New system can reduce lag, and also has configurable tug timer for this - if below say 0.5s then don't trip door force.
- If the door almost closes and you grab it before it hits the mag lock but after it hits the reed switch, you get door forced. New system has locking stage and locking timer, or monitored mag lock input, which means opening at this point is not a door force.
- If you have V locks, they motorise to engage, and so are not instant like a mag lock. This allows a door to bounce and trip the door forced alarm, especially if "slammed". New system allows open whilst "locking" without being a door force.
- The external reporting via ethernet is crap! We have coded it, but it is messy. New system has lots of more direct reporting including HTTP GET/POST, Email and SMS with multiple reporting, and reporting selecting different groups, users, event types, etc.
- Even the proper programming system (rather than using keypad!) is some nasty windows software. New system is currently XML files, but small and easy to work with, and will be some nice web UI.
- Max readers scramble the true number they see so you have to buy special Honeywell key fobs with the scrambled number printed on them in order to use with the Galaxy system. The new system reports the ID it saw from the reader so any compatible key fobs or cards will be usable.
- We'd love to do clever things like expect alarm set by certain time and report, or disable specific PIRs for Roomba at specific times of night. These will all be possible as we add more to the code, including time profiles.
- The Galaxy system allows you to add a new Max reader - it will scan from 8 down to 0 and show the highest reader ID it can see on the bus, then allow you to set it to a new ID (0-3, or 0-7 depending on panel). A new Max appears as ID 8. It does not even say which IDs are in use already, so even for a new install you have to keep track of which you have added. It does not allow you to reprogram any that are not the highest number on the bus! The new system lets you change any Max to any other and reports what it finds on the bus.
- The Galaxy has no way to properly integrate door lock engaged inputs that come from monitored mag locks or V locks. New system does and can detect door ajar events neatly.
- The Galaxy allows door propped timer limits but no way to override on per case basis, hence we don't use them. New system allows key fob to override (if they are allowed to), logging who allowed door prop.
- The max reader beeps (loudly) when door lock released, but I have V locks that make a nice clunk and do not need a beep. Indeed, every Max reader I have seen has blu tack on the sounder as annoyingly loud. New system allows silent door open and then uses beeps as an actual error case, so can be loud.
- User names on the Galaxy are stupidly short making for almost unreadable reports from the system for some users. Also makes it hard to use same names on other systems - we have used Galaxy logs for time recording but needed a mapping of the abbreviated names. New system allows any length user names making it much simpler.
- Of course the Galaxy simply lacks the new features we have now dreamt up, like air-lock door pairs. This is less of a niggle though as we don't need this in the office, yet!
I bet I have missed a few niggles, but you get the idea...
Most projects I've helped with recently have chosen GitHub as their platform. They control the master project, and others can fork it if and as they wish.
ReplyDeleteMy code is rubbish, but here's what a GitHub profile looks like:
Deletehttps://github.com/neilzone
You could have a nice A&A-branded page, and I do think that the overall system encourages filing of bug reports and patches. (I've submitted a few tiny things, and I found it easy enough.)
Without wanting to sound hip, I too would recommend GitHub. It makes contributing that much easier and it is more likely to attract positive attention. Some don't like the fact that it's a proprietary platform but you don't lose much if it disappears.
ReplyDeleteGitHub seems to be the standard for publishing source code / projects these days.
ReplyDeleteBeing a maintainer for a couple of open source projects it has ups and downs. Feel free to get in touch if you want any info / help in setting things up.
No good turn goes unpunished.
ReplyDeleteIs your insurance co happy with a home-made alarm system? I thought they were picky about such things.
ReplyDeleteMy home insurance seem to be. The office does not have contents cover as it was more expensive that being robbed - we are going for "good security in the first place" these days.
DeleteRegarding the question of open-sourcing it or not, I have two questions in reply:
ReplyDelete1) Let's assume that you were selling the software, such that entity A gives you money, and you give them a working installation.
For all of the other software you use but did not write (the OS, libraries, etc.), how are they licensed? In particular, are any of them licensed under the GPL (v2 or v3) exclusively?
If you do rely on any GPLed code, then at the least you'd have to make a copy of that source available (the Linux source, for example). If your code relies on something so tightly that the two things cannot be separated, and that "something" is GPL-licensed, then your code may also become GPL-licensed.
That doesn't mean you have to give your code away for free, but it does mean that your customers could.
2) Let's again assume that you will be selling the software, either just the software or a "full package" of software, hardware, and services. How much would it cost to get indemnity insurance, to cover the costs in the event your product fails, leading to theft at a customer? I imagine it wouldn't be cheap.
It's worth noting also that "open source" doesn't necessarily give people the option to use it however they want. You (that is, A&A) could choose to license it in such a way that people wouldn't be able to do certain things with it. For example, you could try finding an equivalent to the Creative Commons CC-NC-ND license.
So, before looking at what platform to use for making it available, I'd check in to the above questions, to see if your hands might already by tied!
It is just a C application running on linux, so not automatically GPL itself :-) Deciding what licence is one point though.
DeleteA software licence equivalent of CC NC-ND wouldn't meet either the Free software definition or the Open Source Definition. You've basically got a pretty standard proprietary licence.
DeleteOf course, once either the source or binary are out there, anyone can (technically, rather than legally) use it however they wish. Short of putting in some form of DRM / licence validation, and pursuing infringement claims, there's not much one can do...
> I may have vulnerabilities in my code that I have not spotted!. If published, someone could find them and exploit them to rob us, or other people I also have slightly more faith in humanity and would expect someone to tell us if they saw an issue in the code, or at least not bother to exploit it, or at least not have the contacts to let someone else exploit it. So maybe safe to publish anyway.
ReplyDeleteI'd argue that unlike an internet connected piece of software, this is hardware and software that is (hopefully), not connected to the internet. Obviously you (A&A) run this hardware and software and publishing said source code might seem like a bad idea but a) would-be robbers of your clients aren't going to know "Oh this is an A&A based alarm system" b) most common burglaries are done by low-tech criminals. Case in point, when my house was robbed 6 years ago it was because someone left the back window unlocked while going out for 10 minutes. It is my opinion that having transparent and open systems in the long run can make security better.
> It would be a risk to try and exploit such issues
Indeed. Given how this is a physical "hack" and not a remote exploit, you have "one shot" then it's over.
> I also have slightly more faith in humanity and would expect someone to tell us if they saw an issue in the code
Bug bounties can be an incentive for people to find and report security issues, although such for a hardware device doesn't seem to fit in with current models. Or you can hire a competent penetration team annually to test your system if you wish and act on the results. Although it's my experience that systems already made by people and organizations that have "ethos of competent old-time Unix sysadmin types" seem to have not many "catastrophic" vulnerabilities and just some minor ones really.
I remember when reading a while back about your FireBrick devices and your IPSec implementation you pondered if you should open source it, given how FireBricks have signed bootloaders and such. I say in the case of the FireBrick give out the source so people can build it and compare it with the existing image with the digital signature stripped, so people can be "rest assured" that their image hasn't been tampered with. Same technique was used in early audits of TrueCrypt. This also relates to my next point.
> It always helps if there is an "official" version, and if we ever get it to meet security specs or British Standards that also helps confirm which versions does that. But who controls it? There are many ways to release code from just putting it out there, to putting on a community repository, to accepting code updates, or suggestions, or changes, and simply controlling the master copy ourselves.
Again, if you don't feel comfortable with it, you don't have to accept changes from unknown 3rd parties, this could just be as a "for reference" sort of thing.
> If anyone can submit new code, or make changes, one has to be careful. It would be easy to hide a deliberate vulnerability or introduce a accidental one.
All changes would have to be approved by yourself or someone you trust. Or like I said you could simply ignore them.
> I was pondering, for example, I have key fob codes (numbers) and zero is invalid. If someone just removed the if(e->fob) line from the code that does nothing with a zero, then zero would be valid and may match any user without a key fob defined as they have zero stored
Very clever scenario. Reminds me of this: https://freedom-to-tinker.com/2013/10/09/the-linux-backdoor-attempt-of-2003/
Ideally I think a good compromise would be to have the system as open-source but have some license where modified versions might have to use a different name, and have a disclaimer in the readme such as "This is a fork of $Project and is not endorsed or associated with Andrews & Arnold in any form". "No warranty" clauses are standard in many projects.
Of course, this does raise the question of what the hell I call the system. For now, "SolarSystem", but not sure.
Delete+1 for GitHub.
ReplyDeleteI'm rather disturbed to see the "security through obscurity" argument made by you!
(apparently in all seriousness)
Particularly for something like this, is suspect the main money is to be made out of selling the system as a whole (hardware, software, installation, maintenance, support, etc). After all, if it only took a week or so to develop, the software/hardware IP is hardly _that_ valuable.
+1 for GitHub.
ReplyDeleteI'm rather disturbed to see the "security through obscurity" argument made by you!
(apparently in all seriousness)
Particularly for something like this, is suspect the main money is to be made out of selling the system as a whole (hardware, software, installation, maintenance, support, etc). After all, if it only took a week or so to develop, the software/hardware IP is hardly _that_ valuable.
"To some extent it depends how good, and complete, my code is, which is partly why I have delayed releasing so far (I do not think complete enough, yet)." rather misses the point of open source. If Linus had waited until Linux was "complete enough" it would probably never have become what it has.
I quite understand - yes, the security by obscurity argument is not a good one, but I have put here as something to consider (and dismiss). As for "complete", I mainly mean as complete as I am planning to make it, i.e. "not half finished". I think it would be a tad rude to publish something half finished to be honest :-)
DeleteI think it's rude to prevent the community from contributing to the design and evolution of the codebase, personally.
DeleteThe point of open source is that it is never "finished".
No, it won't ever be "finished" I understand that.
DeleteWhat are the implications for your insurance?
ReplyDeleteI doubt they're going to accept your "homebrew" kit as an alarm unless you get it/you certified. I know our insurers won't reduce the premium unless the alarm/company who fitted it are SSIAB/NACOSS certified.
I think you're running the risk of them rejecting future claims if you declared your current system/installer as certified.
I answered that above. That said, getting a system certified should be possible, of course.
DeleteIn my experience (both for home and caravan insurance), the cost of having and maintaining a certified system is greater than the discount applied to the policy for having such a system. Then there's the possibility of a claim being refused because somebody forgot to set the alarm before they went out...
ReplyDeleteIndeed. We did have the system installed by someone certified, and so could have had insurance and so on. As it happens we did not. But I can bet the claim would at least be hassle as the alarm had not in fact been set when we were robbed. Something we have fixed by technical and process changes since.
DeleteIf you fancied an open source alternative to GitHub, you could use GitLab, https://about.gitlab.com/
ReplyDelete> Max readers scramble the true number they see so you have to buy special Honeywell key fobs with the scrambled number printed on them in order to use with the Galaxy system. The new system reports the ID it saw from the reader so any compatible key fobs or cards will be usable.
ReplyDeleteI don't think this is an entirely deliberate thing: I think it's more that there are 2 or 3 different "standards" for the way the EM41xx codes are turned from bits into numbers. We used to have fobs that had one number printed on them, but showed up as a different number in the Galaxy programming (tip, for anyone who has a Galaxy system and isn't aware: when you're about to enter a new user's fob number on the panel, just after you've deleted the old code or 00000, you can press A+1 simultaneously and then hold a fob up to the reader, to automatically type in that fob's number. That way you can use fobs even with the "wrong" number printed on them.)
I once tried to decipher the mapping between the printed number and the Galaxy number, and it turned out to be very simple - can't remember the exact details, but it was mostly about moving bits to different positions, and possibly some BCD - clearly no attempt to make things difficult!
Those were fobs we got from the installer. Now I buy EM410x fobs in bulk from eBay, at about 20p each. As it happens, the number printed on them matches what's displayed in the Galaxy programming...
The keypad reads a different number to the max readers, so you cannot use that trick to make a fob that works on a max reader, only for use on the keypad. Interesting that it could simply be an accident, though.
DeleteIt's a different standard adopted. I cannot remember the reason. As above it's achieved with some out of order bit shifting. I've not looked through your code to see if you've reversed the map back to the standard serial no. I implemented a decoder in a web page for installers to paste a list of cheap tag codes to receive a CSV with the mapping.
DeleteIf you're worried about something nefarious slipping in, you should engage in some "defensive formatting" to complement the defensive coding.
ReplyDeleteFor example, using {...} for single-statement if..else makes it much harder for something to make its way into that part of the code.
Bad idea, the potential liability could take down a&a. Bound to be at least vulnerability somewhere.
ReplyDeleteAn odd answer - making it open source also means you exclude liability for it - people can take it and use it if they want, at their own risk.
Deletesorry my answer was based on selling it as a product aka monetisation.
Delete