So this blew up on Twatter today, after the author of an article I went after on his blog figured out who I was.

Here's the article that I went ape-shit over.

TL;DR: Stronger S2 Z-Wave pairing security process can be downgraded to weak S0, exposing smart devices to compromise.

Z-Wave uses a shared network key to secure traffic. This key is exchanged between the controller and the client devices (‘nodes’) when the devices are paired. The keys are used to protect the communications and prevent attackers exploiting joined devices.

The earlier pairing process (‘S0’) had a vulnerability – the network key was transmitted between the nodes using a key of all zeroes, and could be sniffed by an attacker within RF range. This issue was documented by Sensepost in 2013. We have shown that the improved, more secure pairing process (‘S2’) can be downgraded back to S0, negating all improvements.

Once you’ve got the network key, you have access to control the Z-Wave devices on the network. 2,400 vendors and over 100 million Z-wave chips are out there in smart devices, from door locks to lighting to heating to home alarms. The range is usually better than Bluetooth too: over 100 metres.

Ok, so the claims are basically:

1. S2 is better than S0 (true; it's faster mostly.)  S2 also allows for user-initiated keying exchange with a shared secret of sorts (e.g. a pin code, etc.)

2. The latter is important because during the setup of an encrypted device you have to get the key into the device somehow.  Of course if that key is shared and not hashed with each use by something unique to each endpoint then if you get the key you have it for every secure thing that speaks with the other end!

Oh, and "100 million devices and 2,400 vendors!"  My God, it's full of stars!

Except..... 90+% of those devices do not support encryption at all.  Your common light controls, thermostats, PIRs (motion detectors), etc -- nearly all of them run without any encryption.  They don't get turned on by the neighbors only because their network ID is different, but that's not actual security.  Newer devices support decent (CRC16) integrity checking, but older ones don't.  Don't write that older stuff off though -- despite some misbehavior the old Intermatic CA9000 PIRs are arguably the most-rugged on offer and one of the best options if you don't need pet-proofing, the older Leviton Vizia series of switches and controllers are extraordinarily reliable, etc.  Encryption support is not "free"; it requires "nonces" to be sent around, which consume network traffic, and of course there's a CPU requirement to encrypt and decrypt.  All this means response time is impacted.  You choose the trade-off.  And be careful how you choose it -- for example, if you have a motion detector outside and it's running encrypted the key is in the unit and I could just steal it and then extract the key from the NVRAM at my leisure!  Theoretically the SOCs in these units should prevent that.  Theoretically.

Typically you find encrypted mode support where it matters, which is in devices like locks.  For obvious reasons anything that operates as a lock (e.g. a garage door opening device) without encryption is no lock at all and the part containing the key is in the protected space (in other words to steal it you must first break in, at which point the discussion is academic.)

One of the reasons "universal" S0 is not supported is that it is fairly "heavy" in terms of network and processor (battery, etc) load.  S2 does address this to a material degree so when it is available on a "nearly-universal" basis for devices it'll be a "good thing."  But that day is not today, and probably won't be tomorrow either.  In fact I'll bet less than 1% of all Z-wave units in use today support any encryption whatsoever.

Now let's talk about how S0, which is the "default" secure implementation (the one that's actually in units today), works for a new device.

When you pair a new device the exchange goes like this:

The controller {C} is put into pairing mode (MANUALLY!)

The device {D} is poked (when "clean" pretty-much anything pokes it -- a button press, etc.)

{D} Hi, I am a device of type X and I like you!  --> {C}

{D} <<< Ok, tell me what you are, here's your node number and network id {C}

{D} Thanks, I'm a device type Z here's a few things you should know --> {C}

Now the node talks a bit, along with the controller, and figures out what's in range so it knows how to build it's idea of the mesh of the nodes around it.  It can do this later too, but you REALLY want this to be right or the performance of the network goes to hell FAST. 

Then we look up that "few things you should know" set of data (is the unit always listening, what bitrate does it run at, etc) and looks for a flag that says "I know how to talk encrypted."  If it finds that specific flag set to "on" this happens during a very short window of time (100ms or so):

{D} -----> I want scheme X ----------> {C}

{D} <<< Ok, that's cool, give me a Nonce so I can send encrypted {C}

{D} ----> Here it is ------> {C}

{D} << Here's your network key {C}

Now at this point if we're doing "S0" the potential issues arises.  The node has provided a "nonce", which permutes the encryption so you can't repeat a packet and have it work twice.  (Number once is what "nonce" stands for.)  But the node doesn't have a key yet.  So there's a hard-coded "pairing" set of data which the folks say has a "zero key" -- accurate as far as it goes, but not really because there are three components to the IV (what you initialize the encryption algorithm with) and only one of them is zeros.  Not that it matters in practice, because they all have to be hardcoded, so figuring out what they are is a matter of disassembling someone's controller code or any device's microcode.  But it is absolutely inaccurate to say that the encryption is initialized with all zeros -- it most-certainly is not!

(Remember, the device has to have the same hardcoded initialization value set in it... it does, so it can decrypt that packet and does so, then immediately replaces the working key with the network key it just received) 

{D}  Here's a reply confirming the key set operation --------> {C}

The problem is that during that little bit of time, specifically, that last bolded line, that specific packet can be picked off and since the keying is known you can theoretically steal the key.

If you do then you can proactively read (or send) traffic because the nonces are sent across and thus you have access to them.

In short if you can steal the key well, you stole the key!

The gist of the article from PenTest deals with the S2 scheme, which is more-secure because the user can be prompted to seed the exchange from the console (e.g. "punch in a 5 digit code on the lock, and the same code on the controller") and this makes it a lot harder to rip off the keying.  Further, S2 uses a formal key exchange mechanism so stealing the key isn't a bit harder, it's a lot harder, provided there's a shared secret.  In fact, it's basically impossible.  This is great.

So where's the problem?

Right now there are no commercial controllers that do S2, largely because there are damn near no devices that do S2!  I haven't implemented it yet on HomeDaemon simply because I don't have anything that can run it here, and while I could certainly implement against a single device I'd like to have a few of them to make sure the code is actually stable and I'm not implementing and testing against a buggy implementation that some random manufacturer put out.

Which is quite possible, by the way -- don't get me started on that or I'll talk for hours..... 

The "attack" put forward by the original article is an intentional downgrade attack.  In other words by jamming the device's communications or otherwise tampering with them (remember, this is RF, so you CAN tamper with the transmission by jamming or other means) you can damage the reply packet from the node that says it can do S2.

This will cause the controller to attempt to request compatibility with S0 since it thinks the node cannot do S2, which the devices also support.

Now, during that immediately-forthcoming forced S0 exchange you steal the key.

Note that this is exactly the same risk that exists for any S0 device -- originally, now and forevermore.  It is not unique to the newly-minted S2-capable units.  In fact for an S0 unit there's no need to jam anything.

That sounds ugly, and it would be except for some realities that get in the way of it being ugly in actual practice.

First, the window of exposure is very small and cannot be triggered from the outside.  The controller has to be told to pair, the node has to be told to pair, and then you have to be able to both jam and intercept during a very specific and small window of time.  The frame time for the scheme reply to be valid is about 100ms and if you're off then the node comes up unsecured entirely.  And... you don't get the key because the controller never sends it as there's no agreement on the scheme to be used.  Oh by the way if the node is a lock (I have one sitting here on my desk bolted to two small piece of wood that I use for testing) and it includes insecure then the "lock" functions are missing.  Good, because that will force you to exclude and re-include it so you actually get secure mode (you do want a lock to be able to be locked, right?)

Second and probably the best defense is that best practice is that you pair in low-power mode.  In other words you remove the RF stick from the controller, physically take it to the new device and push a button on it to initiate the operation -- you do not do it from the command console.  In that case the range of the pairing transmission from the controller, which is the only one you care about (since it contains the key) is inches, not 100' or more.

Now for convenience newer nodes (and controllers) can initiate pairing from a distance.  In fact all the 500-series chipset stuff supports doing so.  However, there's a lot of older gear out there that works perfectly well but can't handle high power include, including roughly half or more of the devices in my house.  In fact the standard for setting up Zwave devices and best practice has always been to do so in the final installed location and to pair with the controller at the device.  This is easy when the master is a handheld controller roughly the size of a small remote control as was originally the case with the original Leviton master controllers years ago.  Of course this is sort of hard to do when your controller is this thing that has a wall-wart, doesn't have a separate RF interface and it's running your user interface at the same time!  In other words convenience and poor design of some controllers (essentially all of the mass-market stuff, I might add) means you get to bring the device to the controller, pair it there, and then deal with an inevitable network reorganization to get good performance.

That, by the way, is another sore spot in that many controllers try to do it on their own which is flat-out stupid.  The scope of why is beyond this article (although it's covered in some depth in HomeDaemon's user manual as a caution to people who would try to use those commands without understanding them) but it has to do with the fact that most battery-powered devices are not listening all the time and in order to get a good network map every device has to be on and able to receive and transmit.  Good luck with that on an automated basis where you have anything that runs on batteries in the network.  And if you think this is a "theoretical" pain in the ass there are 53 active Z-wave units in my house right now.  There's nothing theoretical about running around removing the covers, sending configuration commands and similar on over a dozen battery-powered devices so they're all "awake" and can properly participate in a network rediscovery process!  "Best practice" exists for a reason and especially with complex installations it's important to follow it for reasons other than security -- that's a nice side effect.

So the long and short of it is that these guys consider this a protocol problem and severe vulnerability.

I called bullshit on that and they didn't like it.

Here are my reasons; you decide who's right (with their full source article up above):

1. You cannot initiate pairing from a remote, nor over RF.  You have to put the controller in that mode deliberately, and if it is not then it will ignore a unit that tries to perform pairing, never responding to the request at all.  Since it never responds it cannot divulge a key.  Therefore you need a deliberate act by the owner or system installer to first open the potential vulnerability in the first place.

2. You must then initiate pairing on the new unit.  Now this is where things could get sort of ugly; a malefactor could put a "bare" (uninitialized) unit outside your house but within range and pair that.  Then again if they can manage that they can steal the key no matter what because they then take the physical unit.  If you can do that you can build a confederate unit that is designed to get keys and then display them for you.  Bingo -- Bob's Your Uncle.  Note that the only defense against that if you pair in high power is #1 because the unit cannot initiate pairing on its own.

3. Best practice is to perform pairing with the unit in the installed final location using a controller that is operating in low-power mode to pair.  This reduces the potential interception range to inches from ~100' or so whether the intruder is using custom-designed equipment or a simple sniffer.  If a confederate can get a listening device within a foot of you when you are doing this then he can also put a fake node in the same place, trigger it to include whenever it sees some other node trying to do so, and steal the key the hard way -- by retrieving the device later and extracting it from the device's NVRAM.  S2 mitigates this if there's a user-controlled PIN or similar used, obviously, since the confederate would not know what it is nor have a way to enter it and he needs that for the initial keying exchange to be decodable.  Note that it does not matter whether the node runs in low-power during inclusion or not, since the node doesn't send the key -- the controller does, and by the time the node sends an encrypted message it has the actual network key in it and the risk window is closed.  If you have a controller that is fixed-location and doesn't have a removable stick that's an implementation problem and stupid design of the controller, not the protocol, but even that can be overcome -- keep reading.

4. Once keyed it doesn't matter.  In other words the risk is only in forcing a fallback from S2 -> S0.  Further, the standards say that if you do that you're supposed to warn the user.  In fact the fallback chain is S2 -> S0 -> Insecure, and that happens sometimes when including S0 and you get to start over because RF noise or similar corrupts one of the packets; they pass checksum (1 byte and thus not much for integrity; a 1-in-256 chance the packet is smashed but the checksum is good) but fail MAC validation (VERY solid on integrity) and the other end cannot possibly discern what was being said, since the packet doesn't decrypt.  Indeed if the MAC fails you don't even know what the transmission was and the underlying protocol does not have a "repeat last message please" request either.  This happens fairly regularly by the way in ordinary operation; I get MAC/NONCE errors (one of them is bad and thus the decrypt fails, but which?  No way to know) quite regularly on one of my units that's installed in a metal box and thus the RF is sort of nasty-attenuated.  It still works fine and I leave it that way intentionally as a code-robustness test but a fairly decent number of decrypt failures get logged.  And yes, HomeDaemon-MCP does tell you explicitly whether a node is included secure or not, both initially and permanently on the main node display in that secure units have a "*" after their name.

Incidentally this is a severe weakness in the Z-Wave spec but it's not a security concern, it's an operational one.  If you send a packet and it passes checksum the underlying RF protocol considers it perfectly fine and the originating device (which you don't control if it's not your controller where you wrote the code!) can and will overwrite its buffer; that is, it considers the message "delivered" and all is good.  Well, it might not be.  If the CRC16 or MAC computation fails you know you have trash instead of a valid packet but no way to ask for a retransmit. There's a fair bit of code in HomeDaemon that does its level best to prevent that from being operationally significant but sadly if the original event was an asynchronous report (that is, you didn't solicit it so you don't know what it was supposed to be) there's really not much you can do other than log the fact that you got something you can't successfully (or safely) process.

So what would have been a more responsible way to look at this issue from a standpoint of what you could reasonably ask the Z-wave people to do as a means of immediately mitigating this (modest, but real) risk?

There's a very simple mitigation that could be made without breaking backward compatibility in any way: Change the specification for the controller code so that any transmission of Class 98 (Security), Subclass 06 (Keying) always goes out at low power.

That's the end of the problem in real terms; now the interception range of that frame, which is the specific one at risk, is measured in inches instead of tens or even 100'.  And, pleasantly, that's a fix that can be put into controller firmware by manufacturers as a firmware update.

What did I do?

Well, I can't get into the firmware of the RF chip that is used in the Aeotec stick, so I can't fix it the way I'd like, although I can certainly recommend that Aeotec do so, and will.

But what I can do and did is set HomeDaemon's code to explicitly not ask for either high-power or network include unless you tell it to include non-secure only.

HomeDaemon has always had two commands to add nodes; "add-node" and "add-node-nosecure"; the latter intentionally ignores a security scheme request.  In both cases the "add node" command stanza to the controller includes options that (1) can constrain the type of node that it will accept, whether NWI (network-wide includes or only direct) and (2) whether high-power transmission is used.  So the simple delta to the code was to remove those two flags from the "add node" request unless you've blocked secure inclusion for that device.

In other words if you force insecure include mode, that is, you won't answer a request for keying even if the node sends one, then there's no harm in a high-power inclusion since there's no keying sent.  But if you do a "regular" include which allows for secure mode negotiation then high power mode is not requested, nor is network-include.

Never mind that you shouldn't do the potentially-risky thing in the first place; the best and proper way to include a node is to pull the stick out, take it to the node and use the button on the stick to include the new device.  That's how I do all my node includes in testing and recommend it generally.  The range of that operation is inches by my direct experience just like it was with my old Leviton handheld master (which I still have, by the way, although I don't use it anymore) and again, if someone can get a device that can pick off the signal from that close when you're doing it they can just put a fake node out there, pair that, and then retrieve it and steal the key directly.

Incidentally S2 is not a panacea. In order for it to work the seed for the ephemeral key has to be known somehow.  DHE is (elliptic curve) is fabulous and the curve they chose (25519) is the same one that is used by modern ssh2 clients and servers; it has the attractive property of having reasonably-short keying so you can rationally print or barcode it on a unit somewhere.  Since a unit (wall switch, etc) has a very limited amount of storage and CPU power that choice was also driven in part, I'm sure, by those constraints.  Of course if the pairing code is printed on a wall switch and you need to re-pair it you might find it at least moderately annoying to have to remove the switch from the wall to get the pairing code again, and God Help You if the barcode or printing is damaged since there's absolutely no way to guess it.  S2 has a second attractive property in that there are multiple "levels" of trust (three) and does forward nonce computation (assuming there aren't RF errors, which can happen and forces a nonce resync) which reduces both traffic and power consumption.  Those are both good and that's enough reason to support it standing alone once there is a decent selection of S2 capable units available for purchase.

So that's my read on this alleged "terrible" vulnerability.

I'll support S2 if and when I can get my hands on some devices to proof the code against.  It shouldn't be that hard to add; the methods are decently documented.

But until then, and especially if you have devices that use S0 (the "usual" Zwave security) now, take a chill pill instead of the clickbait.  Understand the threat and attack surface -- it's small but real, and you have to do dumb things in order for it to be a problem.  I don't consider this a protocol fault by any means; S2 is faster and, while the keying is better, you typically key a device exactly once in a given installation, so the actual attack surface is likewise very small.

In short be aware of best practices, follow them, and if very odd, unexplainable things start happening ask questions before you just start wildly doing something that some malefactor may want you to do.

You wouldn't answer the phone and give the caller your social security number or garage code; treat this the same way.

And now the FBI gets in on the act....

The FBI recommends any owner of small office and home office routers power cycle (reboot) the devices. Foreign cyber actors have compromised hundreds of thousands of home and office routers and other networked devices worldwide. The actors used VPNFilter malware to target small office and home office routers. The malware is able to perform multiple functions, including possible information collection, device exploitation, and blocking network traffic.

If I remind you I've written several articles on this, going back a while and with the most-recent just a couple of days ago, noting that my HomeDaemon-MCP server, which takes care of security, control and monitoring at my home has been under quite-concerted probing attacks for some time.  

Folks, this crap is only going to get worse.  The simple truth is that an awful lot of coders can't code their way out of a paper bag, a huge amount of software development has been farmed out to "code kiddies" on H1b visas or even shipped overseas to India, and the prevalence of IDEs make coding fast and easy -- too easy.

I wrote the Android HomeDaemon-MCP app in about a week from start to first "breathing" code.  It's now about a month, roughly, since I started working on it.  I had never written a single Android app that did so much as posting up "Hello world" before sitting down to write this, and it's a fairly complex bit of stuff, comprising "always on" network code, display management and various forms of media including both stills and video streams.

Here's the problem: While the handful of external libraries that are publicly released and I use can be inspected in source doing so for the entirety of what is included by those IDEs is a ridiculously complex task bordering on the impossible and virtually all of it has some potential security implication.  Indeed if you read the monthly Android security patch lists at least one serious problem is usually found in MediaServer, which is the framework that handles user presentation of damn near everything multimedia of any sort on an Android phone -- sound, video, images, etc and all of which is embedded into the Android operating environment.  Could you audit all of that?  Well, maybe, if you have man-decades of time to put into it before you release a simple "hello world" app.... and nobody does, including Google who wrote the damn operating system originally!

For this specific reason the Android app stores no login or password data -- not to the system at your house that it connects to, not to the cameras at the house, nothing.  It obtains a key that is of limited validity (the length of which you choose when you set up HomeDaemon at your home or business) when you sign in and never stores the underlying credentials.  If and when the key expires it asks you to sign in again.  No big deal, and if that key gets pilfered due to some underlying issue in the OS then revoking it is as simple as either time or rebooting the controller which doesn't store those on a persistent basis either as part of its security model.

On the other hand someone has to store the actual credentials, and that task goes to the HomeDaemon server, running on the Pi, which is entirely written in "C", by myself, with its only outside dependence being basic Unix operating system libraries and the OpenSSL encryption routines against which it is linked.  That code is not only everywhere it's under active review all the time and, while OpenSSL is a large codebase it's also one of the better-studied pieces of software out there, never mind being able to be upgraded without recompiling HomeDaemon itself since it's dynamically linked.  At worst you have to re-link it.

Security implications are massively compounded as soon as any sort of "cloud" gets involved.  Why?  You haven't read about Meltdown and Spectre?  Note that there are now multiple additional variants that have been discovered and they involve the means to steal data from cloud instances, something I've warned about for years.  There is no mitigation for them available and in fact it may be impossible to fix without major architectural changes in CPUs -- which means for existing computers it will never be fixed and the performance implications of those architectural changes may make them prohibitive for general deployment in any event.  That this hasn't already caused the "cloud" folks to get hammered back to where they really belong (that is, as mass-distribution systems for content intended to be public, like the public contents of a blog) where there's nothing to steal is a shocking testament to the inanity of so-called "IT" people everywhere.

It doesn't help to have the best cryptography in the world if you either leave unencrypted data around or put the keys where someone can steal them!

I absolutely love the convenience that I get from the HomeDaemon-MCP software but I'd never put up with the security problems that come with being connected to any sort of cloud instance for anything like this no matter who's cloud it is!  A "cloud" computer is simply a computer you do not own but lease time on.  The owners are never responsible for your data if and when it gets stolen, because they'd be nuts to take that liability and thus none of them do.

If you want data to be secure it has to be on a machine you own the entire time in a place that is physically secure and under your control, so you know if an intrusion takes place and can do something about it.  The only alternative is that the data must at all other times be encrypted, especially when it is being transported and the keys to decrypt it must never be on a machine that is not owned by you.

You cannot meet that requirement with a cloud-based system because in order to use the data you must decrypt it and that means the keys have to be a computer that is not yours.

The goal of these present thieves appears to be to get inside what you think is a "secure" perimeter.  Most small office and home networks are ridiculously insecure, and many large corporate networks are too.  Why?  Because most of them are wired and the assumption is made that if you can plug into the wall you have permission to be there.  Thus you have all sorts of cute stuff on the "average" small office network included unsecured Windows machines, file servers with open share points and machines that will still take an unencrypted "telnet" or "ftp" connection -- and that's if they don't have wide-open vulnerabilities of other sorts such as unencrypted file storage protocols running (e.g. "bare" NFS or even SMBv1!)

If you can break into the gateway (which is what this newest attack is targeting) then you have established what amounts to a virtual presence inside the building but one the owner cannot see!

Wake up folks.... sending your conversation to a random person in your contact list is the least of your problems.

If you're in this space with regard to home security, monitoring and control, think about doing it the right way.  Look to the right and email me, read here, and here.

No, folks, the hacking has not let up.

As I've pointed out my HomeDaemon-MCP machine has been laughing at state-level style nasties for quite some time, with a few "hall of shame" notes in this column.

Now comes this warning from Talos:

For several months, Talos has been working with public- and private-sector threat intelligence partners and law enforcement in researching an advanced, likely state-sponsored or state-affiliated actor's widespread use of a sophisticated modular malware system we call "VPNFilter." We have not completed our research, but recent events have convinced us that the correct way forward is to now share our findings so that affected parties can take the appropriate action to defend themselves. In particular, the code of this malware overlaps with versions of the BlackEnergy malware — which was responsible for multiple large-scale attacks that targeted devices in Ukraine.

This is exactly why you can't have anything that is potentially-vulnerable on the public-facing side of the Internet at your home or office.

Ever.

The list of known problem devices that are being targeted include a lot of popular WiFi routers, for one, along with NAS devices popular with small and home office users.

I don't think I need to explain why having your office data stash penetrated and stolen is bad, nor why someone getting into your home or small-office WiFi router could easily be catastrophically bad.

The damage that someone can easily do, including spying, theft, alteration of data and similar if they get inside what you believe is a "secure" perimeter network is typically somewhere between severe and, in the case of a business, literal business-ending catastrophic.  Never mind the potential exposure if said party then uses your connection to do something severely-criminal; while the common home user is unlikely to get charged the disruption to your life in having the authorities show up and worse, if you're a small business, what happens to your reputation if such a "take-over" is then abused to ship things around like child pornography ought to be enough to keep you up at night.

This sort of problem is not going to go away, and as soon as you allow anything that might matter to you and is on all the time to be behind or in such a "gateway" you are at severe risk.  As soon as those "things" have cloud access or worse -- any sort of connection to your home's security and monitoring (e.g. IP cameras, etc) and are on all the time the potential for damage becomes compounded dramatically.

Don't believe for a minute that this problem will get "better" if you do nothing and wait -- it will get worse, much worse, since people keep bringing things like "Home assistant" devices with microphones into their houses that are on all the time.

It's one thing if your laptop is at risk through such a problem since your laptop is only on when you're using it for most people, and the rest of the time it's powered down.  It's quite a different matter when you stick something on that same network that is on 24x7, whether you're home or not, and can act in your absence or while you are asleep.

Might want to read this Ticker again....

As of now this problem is, generally-speaking, solved.

Your IP camera does not need to be visible from the outside.  At all.

You also never need to store its password anywhere outside -- not even on your phone.

The HomeDaemon app also never stores the password to either the camera or the HomeDaemon controller; it authenticates using a key that it maintains while running (and can be set to run in the background), and the controller, on demand, negotiates with the camera, gets the unencrypted stream, encrypts it using SSL and a private-CA secured certificate (that is essentially unbreakable), and displays it.

There remain some issues with bandwidth consumption and for that reason I'm not currently using the highest resolution stream capacity available (especially on the 2k+ cameras!) but I have managed to get the latency down to roughly 1 second, which isn't bad at all.

All this on a Pi2, which has about a quarter of the power of the newer Pi3 series.

Encapsulating with the higher resolution and lower bandwidth consumption options is being worked on, as is the ability to move the camera both to presets and arbitrarily, along with setting the camera's presets.  Those latter capabilities are, since I have the camera interface worked out, simply a matter of adding the buttons to the screen.

Are you in the business of providing home automation solutions or selling houses with so-called "smart" features?  This is the one you want.

You can not only control and monitor everything in your house with real time notifications, zero cloud storage or use (therefore nothing to steal!) but the system also integrates fully with any of the Amcrest camera family.

Look to the right for contact info; it's available right here, right now.  Buy it all and make a fortune.

You're not going to like this.

Got a "Ring" doorbell?  Or, for that matter, any of those other nice IP cameras?  Doesn't matter who makes them, by the way.

Most security-conscious people are aware that there's a huge problem with allowing any sort of "cloud" storage option to be turned on.  Many people don't care, but you damn well should.

But here's the other problem that comes with these things: The video stream itself is totally insecure and your credentials are not much safer.

I'm unfortunately forced to recommend at this point that all such devices be immediately shut down in terms of off-premise access to the video.  Period.  Full-stop.  Right now.

The reason is a bit complex, so hopefully you'll read the whole thing to understand it.

Here's a typical start-up transaction for real-time video streaming to one of these cameras:

13:15:16.697677 IP (tos 0x0, ttl 63, id 20712, offset 0, flags [DF], proto TCP (6), length 163)
D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [P.], cksum 0xc419 (correct), seq 1:112, ack 1, win 343, options [nop,nop,TS val 7363585 ecr 37265593], length 111: RTSP, length: 111
OPTIONS rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0 RTSP/1.0
CSeq: 1
User-Agent: Live555

I want to look at the camera in real-time, main channel and normal "substream" (different resolutions, etc) using RTSP (streaming video)

192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0x2c43 (correct), seq 1:143, ack 112, win 905, options [nop,nop,TS val 37265595 ecr 7363585],length 142: RTSP, length: 142
RTSP/1.0 401 Unauthorized
CSeq: 1
WWW-Authenticate: Digest realm="Login to AMC000PD39KR3820JT", nonce="da8
684cec2ea70ff015538fb006139e3"

Heh jackass, you didn't give me any sort of credentials -- go away or tell me who you are with a password.

13:15:16.724851 IP (tos 0x0, ttl 63, id 20714, offset 0, flags [DF], proto TCP (6), length 394)
D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [P.], cksum 0xb072 (correct), seq 112:454, ack 143, win 347, options [nop,nop,TS val 7363588 ecr 37265595], length 342: RTSP, length: 342
OPTIONS rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0 RTSP/1.0
CSeq: 2
User-Agent: Live555
Authorization: Digest username="karl", realm="Login to AMC000PD39KR3820JT", nonce="da8684cec2ea70ff015538fb006139e3", uri="rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0", response="20dc9cda80205b5d2d8f2ae9c335dc27"

Ok, I'm Karl and here's a password for that previously-requested video stream.  Can I have it now?

Note that there is no actual password.  There's a "nonce" and a "response", both of which are not clear text.  The reason is that the camera (thankfully) demanded "digest" authentication.  Note that some earlier versions of camera software allowed "basic", which transmitted credentials -- including the password itself -- in plain text.

Amcrest shut that off about a year ago which is a good thing.  When they did they broke a lot of third-party software that, believe it or not, actually used and relied on plain-text passwords being sent over the wire.  That's so stupid it belies basic logic, but there was a lot of third-party code out there that did.  The fact that Amcrest forcibly disabled this by removing the option from their firmware is one of the reasons I've sort of liked their cameras -- they at least try.

The problem, however, will become clear momentarily....  let's continue.

13:15:16.741703 IP (tos 0x0, ttl 64, id 4151, offset 0, flags [DF], proto TCP (6), length 210)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0x9460 (correct), seq 143:301, ack 454, win 972, options [nop,nop,TS val 37265597 ecr 7363588], length 158: RTSP, length: 158
RTSP/1.0 200 OK
CSeq: 2
Server: Rtsp Server/3.0
Public: OPTIONS, DESCRIBE, ANNOUNCE, SETUP, PLAY, RECORD, PAUSE, TEARDOWN, SET_PARAMETER, GET_PARAMETER

I'm the camera, I like you and your password is good.  Here is what I know how to do with the RTSP protocol.  Please tell me how to proceed.

D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [P.], cksum 0xa4a0 (correct), seq 454:822, ack 301, win 351, options [nop,nop,TS val 7363590 ecr 37265597], length 368: RTSP, length: 368
DESCRIBE rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0 RTSP/1.0
Accept: application/sdp
CSeq: 3
User-Agent: Live555
Authorization: Digest username="karl", realm="Login to AMC000PD39KR3820JT", nonce="da8684cec2ea70ff015538fb006139e3", uri="rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0", response="55f38faa28da02835fdfd2de248f1632"

Ok, please tell me what the stream that is identified as channel 1, subchannel 0 looks like.  Oh, and here's authentication credentials again (note the "response" is different, because the hash includes the command, in this case "DESCRIBE" (with parameters) although the nonce has not been re-generated (this is part of problem #3 I'll get to later)

13:15:16.759068 IP (tos 0x0, ttl 64, id 4153, offset 0, flags [DF], proto TCP (6), length 773)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0xbee2 (correct), seq 301:1022, ack 822, win 1039, options [nop,nop,TS val 37265599 ecr 7363590], length 721: RTSP, length: 721
RTSP/1.0 200 OK
CSeq: 3
x-Accept-Dynamic-Rate: 1
Content-Base: rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0/
Cache-Control: must-revalidate
Content-Length: 506
Content-Type: application/sdp

v=0
o=- 2252311096 2252311096 IN IP4 0.0.0.0
s=Media Server
c=IN IP4 0.0.0.0
t=0 0
a=control:*
a=packetization-supported:DH
a=rtppayload-supported:DH
a=range:npt=now-
m=video 0 RTP/AVP 96
a=control:trackID=0
a=framerate:13.000000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=640029;sprop-parameter-s
ets=Z2QAKaw0yAeAIn5cBbgICAoAAAfQAADLIdDACpIACpFXeXGhgBUkABUirvLhQAA=,aO48MAA=
a=recvonly
m=audio 0 RTP/AVP 8
a=control:trackID=1
a=rtpmap:8 PCMA/16000
a=recvonly

Here's a bunch of information for you describing the media you requested.  The frame rate, the format of it, the audio that's included and its bitrate, etc -- all of which you'll need in order to successfully decode and display the video.  Oh, and your password is still good because I said "ok".

D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [P.], cksum 0xbc55 (correct), seq 822:1249, ack 1022, win 357, options [nop,nop,TS val 7363592 ecr 37265599], length 427: RTSP, length: 427
SETUP rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0/trackID=0 RTSP/1.0
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
x-Dynamic-Rate: 0
CSeq: 4
User-Agent: Live555
Authorization: Digest username="karl", realm="Login to AMC000PD39KR3820JT", nonce="da8684cec2ea70ff015538fb006139e3", uri="rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0/trackID=0", response="a069805debe9e14f99804d37242eac50"

Thank you.  Please set up to play the stream in question (I've decided I can understand it), and by the way, here's another hash (with my password of course) just so you know it's really me.

13:15:16.776718 IP (tos 0x0, ttl 64, id 4154, offset 0, flags [DF], proto TCP (6), length 195)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0xf8ba (correct), seq 1022:1165, ack 1249, win 1106, options [nop,nop,TS val 37265601 ecr 7363592], length 143: RTSP, length: 143
RTSP/1.0 200 OK
CSeq: 4
Session: 372956013002;timeout=60
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=6D23767F
x-Dynamic-Rate: 1

Ok, you're good.  We're ready to go whenever you are, but the session I'm setting up for you is only valid for the next 60 seconds.  I'm going to send it over TCP, here's a session ID so you know it's the right one when it starts and oh, your password is still ok.

13:15:16.780403 IP (tos 0x0, ttl 63, id 20717, offset 0, flags [DF], proto TCP (6), length 435)
D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [P.], cksum 0xb842 (correct), seq 1249:1632, ack 1165, win 362, options [nop,nop,TS val 7363594 ecr 37265601], length 383: RTSP, length: 383
PLAY rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0/ RTSP/
1.0
Range: npt=0.000-
CSeq: 5
User-Agent: Live555
Session: 372956013002
Authorization: Digest username="karl", realm="Login to AMC000PD39KR3820JT", nonce="da8684cec2ea70ff015538fb006139e3", uri="rtsp://192.168.4.211:554/cam/realmonitor?channel=1&subtype=0/", response="b215d803b422a92152c11d1abcf94387"

All good.  Start the stream please, play from time 0.000 on the session ID you previously set up for me.  Oh, and here's my credentials again.

13:15:16.816148 IP (tos 0x0, ttl 64, id 4156, offset 0, flags [DF], proto TCP (6), length 176)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0x97a8 (correct), seq 1165:1289, ack 1632, win 1173, options [nop,nop,TS val 37265605 ecr 7363594], length 124: RTSP, length: 124
RTSP/1.0 200 OK
CSeq: 5
Session: 372956013002
Range: npt=0.000000-
RTP-Info: url=trackID=0;seq=32390;rtptime=2924735

Here it comes!

192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [P.], cksum 0x4d5c (correct), seq 1289:1341, ack 1632, win 1173, options [nop,nop,TS val 37265609 ecr 7363601], length 52: RTSP
13:15:16.871343 IP (tos 0x0, ttl 63, id 20719, offset 0, flags [DF], proto TCP (6), length 52)
D2.Denninger.Net.50501 > 192.168.4.211.rtsp: Flags [.], cksum 0x9535 (correct), ack 1341, win 362, options [nop,nop,TS val 7363602 ecr 37265609], length 0
13:15:16.962682 IP (tos 0x0, ttl 64, id 4158, offset 0, flags [DF], proto TCP (6), length 1500)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [.], cksum 0x5aa7 (correct), seq 1341:2789, ack 1632, win 1173, options [nop,nop,TS val 37265619 ecr 7363602], length 1448: RTSP
13:15:16.962846 IP (tos 0x0, ttl 64, id 4159, offset 0, flags [DF], proto TCP (6), length 1500)
192.168.4.211.rtsp > D2.Denninger.Net.50501: Flags [.], cksum 0xdfe3 (correct), seq 2789:4237, ack 1632, win 1173, options [nop,nop,TS val 37265619 ecr 7363602], length 1448: RTSP

And there it is.... there's a lot more of course but these are the start of the packets containing the actual video.

Now here are the problems, in order:

1. RTSP is unencrypted. This means that the actual video is flowing over the network with absolutely zero encryption of any sort, and anyone in the middle can pick it off.  Watching it on a WiFi network that is unsecured in some coffee shop?  Everyone within 200' of you can see your video.  Is that your cute kid on the "baby monitor" or your empty house?  That wouldn't be a problem, right?

2. Every three-letter spook and criminal malefactor who can access any part of the infrastructure between you and the camera can also trivially decode and display that video in real-time.  Yes, I said anyone.  It requires exactly zero coding or effort to display an RTSP stream you capture; simply feed it to any media player that understands the format and voila -- there you are.  This means that any time you have an actual video stream running anyone who is sufficiently motivated can watch it too at the same time you do or grab the stream, save it to their device and watch it whenever they'd like.  There is not a single online store or financial institution that finds this sort of crap acceptable which is why they all have those little padlocks (https) on their web pages.

3. MD5 is not secure.  That's what "digest" uses to hash those passwords.  It's better than sending them in plain text over the Internet, but not that much better.  While someone who gets a single session would probably have trouble breaking your password someone who manages to get a bunch of these negotiations over time absolutely can do so.  I will note that MD5 was deprecated a long time ago as a sufficiently good digest for hashing passwords in general and it's also not considered acceptable as a hashing algorithm in SSL either, for the same reason -- it's not very hard to break.  If your camera is connected to any sort of "central" or "cloud" service those transactions are all going to one destination and thus you must assume your password has been stolen.  Once stolen, of course, said bad actor can now break into your camera at any time in the future, not just when you're watching it.  Again, I repeat: If you allow your "IP camera" to connect to or if you use any sort of "cloud" storage, control or similar facility you must assume that the login credentials have been compromised.

I've made a "command decision" when it comes to HomeDaemon's app -- it's not going to support doing that as it stands although literally every single damn app out there right now does.  No way am I doing that with my code as it's a blatant and severe security problem.

Instead what I support now is SSL-encrypted transport of captured stills, which is easy because I already use SSL-encrypted transport to talk to the server, the server has the ability to ask the camera for stills already, both are on the same local LAN which is encrypted with AES (and thus reasonably secure) and HomeDaemon-MCP (the server code) already knows how to enforce permissions for sessions so you not only need to authenticate but some users can have access to the camera images and others not, as you wish.  That is secure off-premise right here, right now because (1) the camera is not directly sending the picture, HomeDaemon-MCP is, (2) it demanded and got an SSL connection to the client on the phone and (3) the transport is thus safe from interception or even knowledge that you made the request.

So if you click a camera icon on the HomeDaemon-MCP app what you'll get is the most-recent still the camera has captured, usually configured on the base code to be snapped whenever the camera "sees" movement -- instead of a real-time video stream.

What I'm investigating supporting (if I can figure out how to feed Android's media decoder and display tools bidirectionally with arbitrary streams of data) is a secure, SSL-encrypted tunnel for that video generated by HomeDaemon-MCP and the app, removing the risk for video displayed through the app.  You can then absolutely block all outside access to the cameras, period, at your firewall without losing functionality.  The power consumption on the phone doing this might make you grimace due to the data rate involved but if I can figure it out the transport will be secure.  My first blush look at this is that it's not something either the stock mediaplayer or Exoplayer were designed to handle; the former is part of the framework and not designed to be modified at all, but the latter is an open-source project.  In any event it doesn't look like a "quick" thing to support, if it's even reasonable to do at all given the current state of the Android codebase.  It might not be.

I suspect the reason there is no "RTSPS" is that these cameras simply don't have the CPU horsepower to run SSL encryption for a video stream at the data rates required without puking, and fixing that would massively increase the cost of the cameras.  That makes sense but it means that every single IP camera out there right now is trivially intercepted by anyone sufficiently motivated to do so when in actual use to view video, and any connected to a cloud account gives anyone sufficiently interested a nasty and unencrypted "choke point" through which to collect enough digest information to break your password.

I repeat: As it stands right now Internet-accessible streaming cams at minimum expose the actual video in real time to anyone who cares to intercept it without any sort of real effort and any connected to a cloud service of any sort almost-certainly wind up divulging enough information to make compromise of your password and thus permanent access to same quite easy.

Psst.... if you're in the "home control and monitoring" business, or anything associated with it.... yes, the entire codebase is for sale as I've pointed out before.  Who wants to have the competitive advantage of their systems not being trivially watched by the neighborhood crook say much less organized rings of same?  Email me.....