The content on this site is provided without any warranty, express or implied. All opinions expressed on this site are those of the author and may contain errors or omissions.
NO MATERIAL HERE CONSTITUTES "INVESTMENT ADVICE" NOR IS IT A RECOMMENDATION TO BUY OR SELL ANY FINANCIAL INSTRUMENT, INCLUDING BUT NOT LIMITED TO STOCKS, OPTIONS, BONDS OR FUTURES.
The author may have a position in any company or security mentioned herein. Actions you undertake as a consequence of any analysis, opinion or advertisement on this site are your sole responsibility. Market charts, when present, used with permission of TD Ameritrade/ThinkOrSwim Inc. Neither TD Ameritrade or ThinkOrSwim have reviewed, approved or disapproved any content herein. The Market Ticker content may be sent unmodified to lawmakers via print or electronic means or excerpted online for non-commercial purposes provided full attribution is given and the original article source is linked to. Please contact Karl Denninger for reprint permission in other media, to republish full articles, or for any commercial use (which includes any site where advertising is displayed.)
Submissions or tips on matters of economic or political interest may be sent "over the transom" to The Editor at any time. To be considered for publication your submission must include full and correct contact information and be related to an economic or political matter of the day. All submissions become the property of The Market Ticker.
Market charts, when present, used with permission of TD Ameritrade/ThinkOrSwim Inc. Neither TD Ameritrade or ThinkOrSwim have reviewed, approved or disapproved any content herein.
The Market Ticker content may be sent unmodified to lawmakers via print or electronic means or excerpted online for non-commercial purposes provided full attribution is given and the original article source is linked to. Please contact Karl Denninger for reprint permission in other media, to republish full articles, or for any commercial use (which includes any site where advertising is displayed.)
Submissions or tips on matters of economic or political interest may be sent "over the transom" to The Editor at any time. To be considered for publication your submission must include full and correct contact information and be related to an economic or political matter of the day. All submissions become the property of The Market Ticker.
Considering sending spam? Read this first.
For the second time this month, federal prosecutors say they’ve obtained a trove of encrypted messages from one of President Trump’s former top associates.
The relative ease with which investigators appear to have accessed the messages of Trump's longtime personal lawyer Michael Cohen highlights an often overlooked reality: encrypted apps like Signal and WhatsApp are only as secure as users choose to make them.
Let's cut the crap: They're only as insecure as the app writers choose to make possible.
Why would an app-writer choose to make it possible insecure storage of encrypted communications?
For the same reason you are dumb enough to stick a microphone in your bedroom that allegedly "does things" for you: Convenience.
It it possible to design an app that never stores an encryption key or the content of messages persistently? Yes. Further, Android can be told not to back up data for a given application in the manifest, which the user cannot override.
So why would you, as the writer of an allegedly "secure" application to communicate with someone, put intentional privacy-destroying "features" into your application? Simple: "convenience". Specifically, if the app never stores the messages or keys on a persistent basis then they're not there "later on" and further, if you are in an area without immediate and available data service you can't get to anything at all since it's not present on the device.
If you never store the messages on the device beyond the point at which the user exits the app's "in-use" state (that is, the app intentionally destroys any in-memory or on-storage copies when it is closed, exited or hidden) then they can't be retrieved as they're not there. If they're only transported encrypted with a key generated through secure negotiation then the lifetime of said message in terms of being able to intercept it, absent a failure of the encryption itself, is limited to that of the app's instance.
But this is "inconvenient", you see. Well, ok, "less convenient."
Yet people are led to believe that these sorts of communications are "secure" when in fact they're not, intentionally, due to how the app is designed and works. Rather than explain in great detail that the basis of such a claim is only to prevent interception while in transit and that no security of data on the device is either implied or, realistically provided these folks instead "market" said applications as "safer" than something like a text message.
That may be true but only in the marginal sense, and it does exactly nothing for you if your device is physically compromised or one of the people involved voluntarily turns their device over to someone.
Yeah, ok. Sure.
Supposedly the G-7 is going to have a draft statement about "misuse of computers in the democratic process."
Oh really? Well, how about the alleged "white hat" hackers who really aren't and further, who are increasingly buying access time on major cloud computer providers, including in the United States?
That's becoming an increasingly-real problem and you'd think there would be instant arrests and indictments, since to buy such access you have to provide the company with a billing method which is always traceable.
I've never seen any large company like Microsoft, Google or Amazon deliver services to people without being paid.
But I have seen multiple instances, including several within the last couple of weeks, of computer break-in attempts coming from these major cloud providers and have reported a few of them.
That's a broadly-illegal act and it wouldn't take many prosecutions before those who do this sort of crap got the message: You will be tracked down and arrested immediately.
This is critically important to actually putting a cork into the hacking problem both in the US and abroad because individual IP addresses are fairly easy to isolate and fairly hard to acquire in volume to launch attacks from -- right up until you use a cloud provider service that has a block of addresses that are hundreds of thousands to millions in depth and you can repeatedly access a new one by either making an explicit request or simply standing up a new instance of your "bad actor" code which, with many cloud providers, can be done in seconds or minutes.
It's a lot harder to amass a bunch of random "on some cable company's infrastructure" addresses through compromising individual customer equipment. Oh sure, they're doing that too as I warned about before it hit the press, but this specific issue -- bad actors buying accounts on major cloud provider infrastructure and then using them with impunity is something that ought to lead to criminal indictment against the cloud providers if they either don't stop it when reported and they don't refer it, in every case, to the authorities.
As for the cops if they don't bring the indictments then we need new cops who will.
Nope, nope and nope.
Quick demo of the lock support in the HomeDaemon-MCP app including immediate notification of all changes (and why/how) along with a demonstration of the 100% effective prevention of the so-called Z-Shave hack from working.
Simply put it is entirely under the controller's choice whether it permits high-power keying for S0 nodes. For those controllers that have no batteries and no detachable RF stick, which is a design choice, there's not a lot of option.
But for those who follow best practice that has been in place since the very first Z-Wave networks you're 100% immune to this attack unless you insist and intentionally shut off the protection -- even in a world where S2 adoption becomes commonplace (which certainly isn't today but will become more-so over time.)
HomeDaemon-MCP is available for the entity that wishes to make a huge dent in the market with a highly-secure, very fast and fully-capable automation, security and monitoring appliance, whether for embedded sale (e.g. in the homebuilding industry) or as a stand-alone offering. Look to the right and email me for more information.
So it's not a function of a "mistake".
It never was.
Facebook actually "partnered" with device manufacturers, including Apple, Microsoft, Samsung, Amazon and BlackBerry, and gave them access to data that users had expressly prohibited sharing with third parties.
Bluntly, they stole it.
They (and the manufacturers) lied to users.
They represented that when you said your data was limited to those who you specifically "friended" that it would remain that way, and limited to those individuals.
This was a lie.
Some device partners can retrieve Facebook users’ relationship status, religion, political leaning and upcoming events, among other data. Tests by The Times showed that the partners requested and received data in the same way other third parties did.
So in other words, valuable personal and political data that can and will be used against you by God-knows-who.
In a tense appearance before Congress in March, Facebook’s chief executive, Mark Zuckerberg, emphasized what he said was a company priority for Facebook users.“Every piece of content that you share on Facebook you own,” he testified. ”You have complete control over who sees it and how you share it.”
Lock that ********** up for knowing, intentional perjury before Congress and destroy the firm. and all who work for it and every member of their family. This is unbridled spying, lying and evil defined and it wasn't an accident -- it was and is intentional. And oh by the way, if you are a business that advertises on an evil company's site then you are evil and you deserve to be destroyed and all your employees deserve to be living in a refrigerator box on Lower Wacker Drive in Chicago.
Sigh.... it just never ends.
The garbage claim is that "100 million IOT devices" are at risk.
That is a flat-out lie.
Z-Wave has been around for quite some time but virtually zero of the installed base of devices (which might well be 100 million units) have any secure operation capability at all. I'm willing to bet less than 5% of all sold devices in the field today have any security (e.g. the common wall switches, etc) and of those that do have it with the exception of access control devices (e.g. door locks) less than half, and probably less than 5%, of the installed units with that capability are using it.
For example I have a handful of Aeotec's "multisensors" here. They're quite nice, delivering not only occupancy detection (IR motion sense) but also temperature, humidity, light level and, when it works (which isn't very frequent) UV. The latter is a sore spot in that most of the examples I've seen either fail in service on UV or don't work out-of-the-box. Since the unit is not rated for outdoor installation, however, I'm not sure why anyone would care that UV doesn't work -- of what use is reporting UV level indoors?
In any event it can be included secure but most people would have no reason to do it, and doing so impacts both battery life and performance since you must exchange a NONCE before you can exchange a frame. RF transmitting is (from a battery point of view) god-awful expensive and everything else is extremely cheap, so using it in "encrypted" mode likely cuts your battery life roughly in half.
That, by the way, is why S2 is important on a forward basis; it includes forward nonce-generation which means that as long as you don't take a network error and have to resync the nonce the battery power impact of using it will approach zero. This is a very good thing for battery powered devices, of which most of the devices where security is really important (e.g. a door lock) are.
But the first and foremost point of contention is that the claim that "100 million" IOT devices have been rendered insecure due to a protocol problem is a bald-faced, scaremongering lie. Virtually all such devices today are not secure and never will be and thus they can't be impacted.
One of the other claims raised is that S2-devices are common or "all new devices" are. Well, no they're not on either count. Yes, allegedly all new devices since a date now-passed must be S2 capable. However, in fact that's not true and further, if you go here and select "S2" you'll see the list of devices that do support it. Five pages of roughly 12 each is 60 devices. Or is it?
No, and here's why. Look at the Honeywell thermostat. Then keep looking at the pages; see anything odd? It's listed twice with two different firmware revisions! Now maybe that's due to differences in the RF frequency set (which is what I expect it is), but that in turn means that the alleged list is over-representing reality. Then there's a second problem which is that some of the alleged units are not deliverable; Aeotech's little NanoMotes, for example (which look real nice and in fact I can think of some good applications for them around here in places where the "Minimote" might currently be used) are not deliverable at present. Then there's a Z-Wave repeater which allegedly is "S2 capable" which is laughingly stupid since a blanket packet repeater (used for range extension or "bridging" between places where Z-Wave devices are) doesn't care what goes through it. Repeaters are, generally speaking in the Z-Wave world, stupid in the first instance since all line-powered active nodes repeat and route as an inherent part of how Z-Wave works. In other words instead of spending $50 (or whatever) on a repeater, which requires wall power, you should spend the same $50 on some useful thing that goes in the same place, even if it's something as trivial as a plug-in doorbell chime.
But let's get back to the root issue here which is the premise of a forced downgrade attack. This raises the sort of eyebrows that it did when a similar means of doing so was discovered with certain versions of SSL software that could impact web servers, forcing their encryption mode back to easily-broken options.
There are enormous differences between that sort of attack, which can take place from literally anywhere and can happen with any encrypted session establishment at any time and an attack of this sort, and every one of the differences makes this particular claimed attack far less-severe and, more importantly, able to be mitigated.
There's a not-amusing aspect to this, however, that I'll get to in a bit -- so yeah, you should read the geeky part in the middle that starts under this paragraph so you don't miss the punchline.
As I point out in my original piece on this "best practice" with Z-Wave has always, from the first devices ever invented (yeah, I was playing with this and writing code against it when the first Leviton Vizia-RF units were released) to do unit inclusion with a handheld at the new unit's final location. Why? Because (1) it's more reliable since those few frames have to get to and from the unit unmolested or really bizarre and bad things happen, (2) the Z-Wave checksum is a one-byte CRC which means the odds of a smashed packet passing its check is 1-in-256 (quite good) and (3) the newly included unit and all the other ones around it need to be able to send and respond to the probes on the network sent during inclusion that establish what each unit can "see" so the mesh routing works well.
The original "master" controllers (that did includes) looked something like this:
Yes, it still works and I still occasionally use it for testing purposes, but not on my "live" network here. All of the original Z-Wave "computer interfaces" were secondary controllers and could not do inclusion (e.g. the Leviton RZCOP); you needed one of these handhelds to set up and maintain the network. They weren't cheap either and while they could be used to control four devices directly they otherwise served no real purpose which had a fairly severe dampening effect on adoption of the protocol among "ordinary people." In other words you bought one to set your network up and then it sat in a drawer (hopefully with the potential leaking batteries removed since you might not touch it again for a year or more!)
This was all before S0 was around, incidentally -- that handheld has absolutely no idea what secure anything is.
So around come the newer chipsets and so does this ability to forward the frames that need to be sent to include a node. Thus the controllers started sending those frames at high power, instead of extremely low power at which the range is inches. This was a demonstrably bad thing because it's pretty easy to wind up accidentally including the wrong unit if there is more than one that is "bare" (not included) when you start that process. A wall switch, for example, that is unpaired will pair if the controller is in pairing mode and its button is touched. If there are three such switches and you put the controller in pairing mode you better push the right button or you get the wrong unit included. What's even more fun and stupid is if your neighbor has a unit that's "bare", he's within RF range at full power, and you put your unit in pairing mode. Now you might get his switch on your network! I'm sure you can imagine how much you'd enjoy that.
Now if I want to be a real prick and live in an apartment I'd buy a Z-wave stick and write about 10 lines of code to talk to it that locks it in include mode. Now anyone within RF range of my unit that tries to pair something is likely to wind up with me owning their device!
Using low-power and having the controller at the unit essentially eliminates this risk because the range of communication is all of about a foot. Further, if you have any older units that can't forward network include in your network there's a decent chance trying to include a unit on "high power" won't work anyway. Maybe nobody cares with an all-new, 2018 installation of all devices with 500-series chipsets in everything in the building but there's a hell of a lot of installed units that pre-date such -- I've got a couple dozen of them in active use.
Don't write that older stuff off either; much of it was built before everything went Chineesium Garbage. The Intermatic CA9000 PIRs, for example, have a couple of nasty firmware bugs but if your code can compensate for them they're extraordinarily rugged, have very high sensitivity yet almost-never false and work fabulously well (provided you don't need pet-proofing); indeed although not rated for outdoor use I have had one outside my house, under an awning, for more than five years as a primary sensor for someone approaching the front door and it still works perfectly well. Try that with any of the "current" stuff on-offer and you'll be lucky if it doesn't short out inside of six months and utterly none of the more-recent stuff I've tested has the sensitivity and selectivity of these.
One problem we do have with "IOT" in general and consumer products in particular is that nobody pays a damn bit of attention to best practices if they interfere with something being "pretty". Thus you now have mains-powered hubs sold by various vendors (lots of them) that have exactly zero means of detaching the RF piece and taking it to a new unit. That in turn has made "network wide include" really, really popular. And for non-secure devices, other than the risk of your neighbor including your unit or you including his by accident or malice, this appears to be a "feature add" that comes with no cost. Heh, who doesn't like that, right?
How hard would it have been for the SmartThings or Wink people to put a small battery in the unit so that it can run for a while unplugged from its wall-wart allowing you to take it to a new unit to do includes at low power? Not hard at all, it would have maintained long-standing best practice -- but that would have added two bucks to the price for a 100mah lithium cell and they didn't give a crap about best practice that has existed since Z-Wave was introduced so.... yeah.
Now add secure-mode operation, however, and an immediate problem arises.
To securely communicate with anyone you must somehow exchange a key. That is, you must somehow get a shared secret between the two of you. Asymmetric encryption (E.g. RSA, ECDH, straight DH, etc) is useful for getting keys exchanged between people but not particularly useful for passing large amounts of data. For the latter you use a symmetric cipher -- that is, given the key and identical initialization components anyone can decrypt or encrypt. To keep people from sending the same message twice the usual method is to include a "nonce" that gets either generated or sent between the ends and that becomes part of how the cryptography is initialized for a particular message; once used it's intentionally destroyed by the receiving end so an attempt to re-use the same nonce fails because the receiver has thrown it away and he can't decrypt the second copy.
Once I have a symmetric key until and unless I have to re-key it's valid.
Now here's the important part: Keying via secure means is computationally expensive while symmetric encryption is computationally cheap.
So how do you get the key into the two devices?
Well, on the controller it's easy; the user either chooses it at the time they initially install the controller or it's randomly generated at that time (hopefully with a very strong, and good, source of randomness in either case.) But what about the other end?
A wall switch, a thermostat, a lock or a sensor doesn't have a reasonable way to load a 128-bit key into it as they don't have a keypad that's suitable for that or, in many cases, any sort of keypad at all. Z-Wave could have mandated a USB port on the units to which you could plug in a handheld controller or even a phone or PC and loaded it that way, or for that matter an IR receiver. But they didn't. They do the keying over the air and thus how that happens becomes critically important.
For "S0" (the vast majority of all installed "secure" Z-Wave devices) "how it happens" is via one specific frame sent by the controller, Command Class 98 (which is used for all S0 "Secure" things), Subclass 6. That specific frame is only issued once, during the inclusion, and contains the key encrypted with a fixed key and set of initialization values. A nonce is negotiated first but doesn't matter because it too is sent in the clear. The upshot of this is that if you can listen to that frame you can steal the key but you must be physically where you can do that and the installer or user must deliberately put the controller in pairing mode and pair a unit that asks for security.
There is about 100ms of time during which this frame can be requested and must be responded to in order to be valid. At no other time, ever, is that frame sent by the controller. Thus the specific window of vulnerability is very short in time, it never occurs randomly nor can it occur by remote command, that is a potential thief cannot cause it to be sent. The potential thief thus must get you to put the controller into the mode where it is willing to send that frame. This need occurs very infrequently in an installed system; unless you have a unit fail or wish to add a new one it simply doesn't happen. In short you never put the controller into that mode under normal operation.
This is where reality collides with best practice.
If you remove the RF interface stick from your controller and use it to include an S0 node now not only do you need to do it deliberately (as is always the case) the range of interception is measured in single-digit feet. With specially-designed (e.g. a beam antenna, etc) hardware you might be reasonably able to extend interception to 10 or 15' but doing so makes the device to do it relatively large and essentially impossible to conceal. The range of interception with something small (e.g. pocketable) is measured in inches.
These ranges are also in "free air"; put a wall between the two and as anyone who has ever taken a 2.4Ghz WiFi device between two rooms separated by a wall knows the signal (and thus range) is quite materially degraded. RF obeys the inverse-square law and that is not your friend if you're the bad guy!
But if you allow network include to proceed with S0 under any circumstance then it certainly is possible to pick off the key at a reasonable distance (tens of feet without special gear, maybe 100' or more with it if you don't care about size) because the frame is repeated network-wide.
So why did controller manufacturers allow this and why did not the Z-wave folks withhold certification from controllers (not end-devices) that allow this sort of thing?
User convenience damned best practices that Z-Wave has always had to Hell.
S2 makes this issue more complicated rather than less. With S2 there is an ECDH key that has part of it burned into the node and part of it public (usually on a QR barcode.) That's classic asymmetric keying but now there's a problem -- you have to get the public half of the node's key into the controller to pair it because it needs that to send a message to the node that only the intended node can decrypt.
This sounds like a great improvement and it is but for one problem -- you have a bunch of S0 devices out there and you cannot orphan them. Further, there's absolutely* nothing wrong with them once they're keyed in terms of security, so there's no reason to deprecate S0 devices.
(Note the asterisk, it's theoretically real, but heh, the guys who wrote the original don't seem to understand why, and that asterisk probably applies to S2 as well -- I haven't analyzed S2 thoroughly enough yet to know with certainty. That's something I've been aware of for a couple of years and is an article for another time.... maybe.)
And by the way, once the node is included S0 and S2 are roughly comparable in security. Both use symmetric 128-bit AES. S2's advantage is that due to forward-nonce capability it is faster and consumes less power; the former is not a big deal (100ms .vs. 200ms isn't all that material in response time) but the power savings for battery-powered units is very material (perhaps as much as 50%!) However, operationally once included S2 and S0 do not appear to be materially different in the security of actual operation as both use a symmetrical key of the same size and the same algorithm.
So if, during an S2 network include (which is secure as only the intended target can decrypt the keying message) you jam the negotiation the unit will fall back to trying S0, thinking that the controller cannot actually do S2 and when it does that the controller will "conveniently" send the S0 key over the network with network routing enabled and at high power.
The reason S2 makes the S0 problem "visible" and much worse is that with S0 I can take the stick out of the controller, take it to the node, and reduce the potential interception range to inches. I cannot do this with S2 because I have no way to enter the node's public ECDH key half into the stick as it doesn't have a keypad!
Therefore my original recommendation set (which hasn't changed):
1. For S0 nodes, which are the vast majority and in fact S2 can fall back to it, if you do not need or care about the battery life improvements, do the include at the node using a detachable stick. If your controller doesn't have a detachable stick and cannot be forced into low-power mode for secure inclusion buy a different controller as your controller is intentionally broadcasting keying at high power in an insecure manner and this has been known since S0 was first introduced. In other words the vendor of your controller does not give a crap about security and never has. This is not a newly-discovered thing nor a "flaw"; it in fact is part of the original design and yet was considered operationally immaterial by a whole lot of people, myself included, because the effective range of interception of a low-powered inclusion is measured in inches and could not be triggered except by deliberate owner or installer action.
2. FOR EMPHASIS - THE VENDORS THAT HAVE NOT MITIGATED THIS IN THEIR FIRMWARE AND MAKE IT IMPOSSIBLE FOR YOU TO DO SO VIA BEST PRACTICE (FOR EXAMPLE, BY NOT INCLUDING A BATTERY SO YOU CAN TAKE THE CONTROLLER TO THE UNIT) DO NOT CARE ABOUT SECURITY. THE CORRECT PLACE TO DIRECT YOUR IRE IS AT THEM, NOT THE PROTOCOL DESIGNERS OR MANUFACTURERS OF END-NODE DEVICES SUCH AS DOOR LOCKS. THIS ISSUE WAS NOT CONCEALED AND IT HAD A PERFECTLY-LEGITIMATE BEST PRACTICE MITIGATION THAT MADE IT OPERATIONALLY INSIGNIFICANT.
3. For S2 nodes, until and unless the manufacturers fix their gateways so that under no circumstance is a Class 98 Sub 6 frame emitted at high power if you're concerned about keying leaks the only sound option is to again do as in #1 which means including them secure under S0 by taking the stick to the device. They cannot be included as S2 without the risk appearing since you can't get the key into the stick to do an S2 include with the stick unplugged!
4. IF you're going to go after the Z-Wave people (e.g. the alliance, the people who issue "certifications", etc) then you have a legitimate beef in exactly one fact set: They are certifying "gateways and controllers" that can and do emit Class 98 Sub 6 frames at other than extremely low power where the effective range of interception is measured in inches. That was stupid originally and remains stupid. It's also easily corrected since you only need to change it on the controller firmware; node firmware doesn't matter. That vendors have built controllers with no local power and thus fell back on a "convenience" feature set at the cost of security isn't the fault of the protocol designers. If I leave a key in my car's ignition with the window rolled down I should not be surprised if someone steals the car!
The discarding of long-standing best practice and indeed the only way inclusion could be done originally under Z-Wave on the alter of "convenience", as it collided with improved keying, produces a potential problem -- albeit one that is easily rectified in controller firmware. The actual units in the field (e.g. wall switches, thermostats, sensors, etc) do not need any changes made to them whatsoever since they never emit the frame in question -- only an including controller does.
It is thus entirely appropriate to raise hell with the Z-Wave folks and controller manufacturers about controllers emitting S0 keying at high power driven by their failure to include enough backup power and a means to do inclusion by taking the controller to the unit when secure units are to be included. That's what changes a theoretical but nearly impossible to exploit issue into one that can be exploited from a material distance without first breaking into your house (at which point all such security is irrelevant of course.) It is perfectly acceptable to do insecure includes at high power (for convenience) since no secret is exchanged in that instance.
In the meantime folks calm the hell down. To actually exploit this problem you need to include an S0-capable device (or a confederate has to be fast and lucky enough to forge an S0 scheme request frame without it being smashed by legitimate exchange during inclusion, which is not easy and may not be plausible in terms of actually doing it with any sort of reliable outcome.) That in turn means the owner or installer must be conned into putting the controller in inclusion mode for some reason while the confederate has a listening unit where it can get the signal during that specific 100ms window of vulnerability.
As such for all existing S0 units follow long-standing best practice which means including locally at the device using a controller or stick that can do so at low power. For newly available S2 units at present it means doing the same thing and using S0 until controller manufacturers fix their code so as to prohibit S0 keying at high power, which will break the attempt to downgrade; if a confederate attempts to force a downgrade with S0 high-power keying disabled he won't get the key and the unit will come up insecure, at which point you know it failed to include secure and you can try again (maybe after looking for an intentionally-interfering device and, if you find one, shooting the person possessing or controlling it.) If your controller can't do that because it's mains powered without either a detachable, battery-enabled stick or a battery included in it so it can do low-power local include you bought a device where the manufacturer opted to intentionally emit effectively-uncrypted secure data at high power for convenience, sacrificing actual security in the process. Get mad at them for marketing such a thing or get mad at and shoot yourself for buying such a thing. They sold you something that is roughly equivalent to selling a car with a spare key taped up behind the bumper where ANYONE can get it while the fact that's where the spare key is has been published information for the last several years.
Of course who knows whether any of the various manufacturers of controllers in the mass market will ever give a crap about security or whether the Z-Wave folks will either. But in terms of actual exploitable risk this one is pretty far down the chain.
Incidentally this isn't far-removed from the idiocy of "keyless, buttonless" car locks which I've previously written about and was called all sorts of names for right up until thieves started actively exploiting it and stealing cars out of driveways and parking lots, at which point (two+ years later) it finally got some attention. Not one car manufacturer has stopped doing it though and indeed it's getting harder and harder to find new cars without that particular stupidity. There's nothing necessarily wrong with keyless but when you combine it with buttonless now a pair of thieves can trivially use a pocketable repeater to make your car think you're standing next to it, open the door, and then make it think you're sitting in the driver seat with the key so the thief can simply push the button, start it and steal it! Why did you buy something that braindead? Because pushing a physical button on the fob to unlock the door is too hard?