Here's some more on the license server that was recently added to HomeDaemon-MCP.

One of the biggest issues that faces any software publisher today is piracy and security.  The two are intertwined; not only do you lose sales (maybe a lot of them) to piracy, but what's worse is that stolen copies of the code frequently have "special features" (viruses and similar nasties) added to them, and since most software installers run with privileges this is a huge problem since the user grants permission for the code to install.

If that happens to include a trojan, cryptolocker or other nasty the user is screwed.

HomeDaemon-MCP of courses faces the same challenge, were I to start distributing it or if someone buys it and starts distributing it.  The code also inherently uses cryptography via the OpenSSL library, which it must to (among other things) provide a SSL-protected web server so you can control and monitor your home without other people breaking in.

For those who haven't run a web server with a certificate before in order to have the little padlock show up on user's displays you must have both a certificate and key.  The certificate is public and anyone can retrieve it but the key must remain private.  In addition someone has to "vouch" for that certificate and key belonging to you as being actually yours, which is why there are companies that sell said certificate certification services (e.g. Comodo, Verisign, etc.)  The idea behind "public" certification authorities is that they allegedly actually vet who someone is (at some level, which depends on the service bought and paid for) and supposed are trustworthy (that is, they won't allow anyone to impersonate them and, for example, issue a bogus certificate.)  There's plenty of reason to believe the latter is definitely not true if the person doing the insisting on impersonation is a government agency, by the way (since a government can insist rather loudly including by locking people up or even shooting them if they refuse), but for ordinary brigands and thieves it's probably secure against such games.

In the realm of a private device there's no reason to pay for a public certificate though; you're not a business taking money from the random public. In that case the company that sells you the "thing" is, if trustworthy (and if not why did you give them money?) probably good enough.  However, the requirement for a certificate that is vouched for by someone you trust still exists or anyone can stick a random certificate that claims to identify your site "in the middle" and by doing so decode all the traffic and steal it -- including your password, at which point breaking in becomes pretty darn easy!

HomeDaemon-MCP has always allowed you to specify who is the "root" of that trust in the certificates it uses.  This is now part of what the license server provides.

In addition the certificate and key are also provided by the license server.  That is, formerly if someone stole (or "borrowed") your SD card they could trivially read the key file since it's physically there and virtually any computer can read an SD card -- suddenly your system is not secure any more.  That's because if the key file has a password on it (which would prevent its use, at least without a lot of resource to crack it, as it's encrypted) the software can't start on its own after a power failure because there's nobody present to put in the password.  This by the way is true for most web servers as well, which is why most of them in "ordinary" commerce rely on the physical security of the device rather than a password on the private key for the certificate in question.  This is mitigated by the fact that if your certificate is compromised (e.g. you learn someone may have stolen the key file) you can ask whoever issued it to revoke it and reissue a new certificate, which of course you'd do after generating a new key (and fixing however the old one got stolen.)  As a result the utility of stealing a key on a webserver is somewhat limited since the certificate it is linked to is easily marked compromised (in other words explicitly "do not trust this") and replaced.

What's been coded into HomeDaemon-MCP to effect the "boot up" is a pair of certificates -- that is, CA certificates to validate the connection to the license server.  There is both a root certificate (for which the key is stored on an offline piece of media in a safe and an "intermediate" certificate (which has its key available to sign regular certificates.)  This particular intermediate certificate signs only one server certificate -- for the license server.  Rather than read them from a file the system instead has them coded in the executable.  If these keys are stolen from the server side, that is, if whoever is running the license server itself has a security problem then you'd have to reissue all the keys anyway since you must assume they've all -- including the server's certificate and issuer certificate -- have been compromised.  As a result there's little downside to this approach; if such a breach occurs then the binaries would have to be recompiled and re-issued and until they are, the old ones would refuse to talk to the fixed license server with its new certificate chain.

In addition the server and client sides are both coded to insist on extremely high security connections; if a client tries to connect using something that can be replayed or is not sufficiently safe the server will refuse.

Now when the HomeDaemon-MCP code starts up it asynchronously starts to not only run as usual but also tries to acquire a license set.  It does so by sending a unique hardware ID, a user-specified password and cryptographic hashes of both the executable being run and the operating system kernel.

The server then validates all of this against its data, specifically:

• Is the hardware ID known to the license server?  That is, did the user steal the software and is trying to use it on multiple (or an unauthorized) piece(s) of hardware?
  
  
• Is the password correct?  That is, is the user's assertion of being the owner of the hardware in question reasonably "good"?
  
  
• Is the executable's hash good?  That is, not only has it not been tampered with (essential) but is it an authorized revision (useful)?  This allows the license granter to, for example, only allow "free" updates for a certain period of time.
  
  
• Is the kernel's hash good?  This is one the license granter may not care about, but on the other hand they may.  It provides the ability to gate support and operation to a list of known-good operating system kernels.  Since a tampered-with operating system is even more dangerous than a tampered executable this is arguably quite a good thing.  However, it is somewhat limited in that the overhead cost of real-time cryptographically checking every operating system component is extremely high, and thus that's not attempted.
  
  
• Is the place the connection is coming from ok?  The current code doesn't check IP addresses against a white or black list, but there's no reason it can't since every connection has an endpoint and TCP connections will not work unless they are valid in both directions.  This doesn't stop someone from "bouncing" off another address but it can prevent someone from using a license in an area that the granter considers "prohibited" (e.g. Iran, China, etc.) without the user taking extraordinary steps.

If the server doesn't like any of the parameters passed to it then it simply shuts down the connection and goes away with no response at all.  The client code will keep trying a couple of times a minute.

If and only if it likes all of the parameters provided then it responds with an operational CA chain for the web and master server, the certificate and key for same, and, if the client is authorized to run as a slave node, the certificate and key for that (which is distinct from that used for the web server.)  All of this is sent over a PFS-encrypted channel and thus is useless if the raw data is captured and replayed even if you somehow manage to later steal the license server's private key.

The HomeDaemon-MCP code installs those credentials and as a result encrypted mode operation, including web access, immediately becomes functional.  A couple of times a day, or if the code is restarted (e.g. after a power failure) the same scenario repeats so if updates are made to the license data the new certificate(s) and key(s) will be loaded.

Since access to the web server functionality is pointless if there's no web access at all (e.g. no access to the Internet) the short delay during startup means nothing since you, as the user, can't get to the service until internet access is restored.  Because license acquisition takes place asynchronously event processing starts immediately and operates normally even if the server is unavailable for some period of time -- but you can't get into the system to manually control or monitor it as the web server (and master capability) is effectively non-functional, immediately closing any connection attempted as the system knows the security credentials are missing.

At no time is any of the returned data stored locally, and there's also no buffer space in which to stash it in the code; instead it is dynamically allocated as required and then immediately cleared when no longer needed.  Therefore if you were to force an attachment and RAM dump of the executable you might be able to recover the credentials, but the the amount of code-hacking you'd have to do to make that information usable in the binary would be quite severe.  The other alternative would be to hack the binary to disable secure-mode operation entirely.  However, if you managed to pull off not only killing the checks but also enabling the access without the credentials you would basically destroy any pretense of security in the application itself and thus render it not only worthless to the user but potentially quite dangerous since random people on the Internet could quite-trivially break in and/or steal your login and password!  In addition if the legitimate licensee figures out you did any of this with his certificate and key he can sign into the license sever's client side and request that the server revoke it.

As such this appears to be pretty good as a security model.  Nothing is perfect; all commercial applications suffer from some risk of hackery and this is no exception, but as applications go since access to the outside world is basically required and secure access to same is also required in order to make it safe hacking out the protection scheme, if violated through hacking on the binary, leaves you with a highly-compromised piece of code that nobody in their right mind would use to control anything.

The License Server code as it sits right now runs against a flat directory structure and doesn't check kernel and executable hashes, or against a Postgres database -- with the query process entirely configurable.  The latter is also multi-threaded making possible very high levels of performance.    What won't be included is the customer-facing front end that handles people setting up their accounts and paying, since that's highly specific to whatever sort of payment model and collection system (e.g. credit cards, PayPal, etc) you wish to use.  I can of course code something along those lines up for a price -- or you can, if there's not already an appropriate "cart-style" web application that fits your needs or that you already have.

As a reminder HomeDaemon-MCP is for sale "lock, stock and barrel" and in source form; my previous article on the potential market is here, and the page on some of the capabilities can be found here.  Finally, there's a not-yet filed provisional patent related to the code that, for obvious reasons, I won't be going into any sort of detail on but will file same before turning over anything that could lead you to figure it out.  Who knows what that's worth, and the acquiring party will be free to file the permanent application and pursue its perfection and issue, should they so choose.  It's entirely possible that patent is more than worth the asking price on its own, incidentally..... but of course as with all things of this sort nobody knows until it's filed and marketed.

Look to the right for contact information.