I searched a bit more on the www but it seems that CSA itself doesnât want to provide information about this (nasty?) topic?
Instead found something interesting on espressifâs site which actually says that the âkill switchâ also works for already provisioned devices as they periodically go online to see if they are allowed to continue working normally or if they should turn into a
Upon discovering the revoked status of the device, the commissioner can notify the user. It is then the userâs responsibility to make a conscious decision regarding whether to allow the device to operate with limited functionality or not
Some not further described âlimitedâ function might still be availability to the âownerâ.
The kill switch (certificate revocation) might also be triggered automatically upon (normal) expire of a certificate.
Certificate Revocation Lists (CRLs): Using Public Key Infrastructure (PKI), Matter now supports standard mechanisms for revoking unused or compromised Device Attestation Certificates. Ecosystems can use CRLs to flag potentially risky devices, warning users during commissioning and blocking unsecured devices from entering the network.
I have 2 minds about it, yes I find it concerning, yes I am glad that word is spreading awareness about it.
But like any type of âsecurityâ, you give up some level of freedom.
Like most things in life, it is a trade off.
I think personally, I currently have a few matter controllers, donât have any actual matter controlled devices, and I am less likely to choose matter over zigbee or zwave anyway, even though I believe that both zigbee and zwave may also support PKI.
I can imagine the representatives from all the big IoT firms sitting around the table discussing all the great reasons why they should include this âfeature.â And the lone voice of someone representing the buyers of their products being drowned out and voted down.
I imagine this was seen primarily as a great way to force customers into paying for subscriptions, ensuring a revenue stream for the manufacturer.
Iâve never seen this happen with Zigbee, nor heard about it happening with Z-Wave. I hope it stays that way!
Edit: Looking back, I now remember how my whole attitude toward Matter changed when I heard there was a required âcommissioningâ step. This sent up so many red flags for me that Iâve sort of lost interest in the whole thing since then. So I guess this isnât really ânews,â but more of a spotlight on an existing area of concern. Which is good.
So you think z-devices might use some certificate which, when expired, could also limit device functions or disables it completly, like it seems the case with matter?
Interesting thought. Both Z-tech being around for longer then a decade the validity of such certificates probably needed to be 15, 20 or more years to didnât annoy users yet.
While technically not necessary to trade security for freedom it is mostly a pure comofort thing. For example by default Microsoft is so âniceâ to backup the secret of your locally encrypted drive in their cloud⊠That way if you loose access you can just ask Microsoft for help to get access to your drive again Linux users on the other hand have no automatic cloud backup and if they donât take care of some backup they might loose access in case of an incident
Correct me if Iâm wrong: I guess that this kill switch will kill the cloud compatibility but local control will still be available with a warning. Because I think local control can override a certificate revocation list.
I think that would entirely depend on the other matter devices on your network and if you can have them ignore CRLâs or if they simply donât validate certificates at all. Iâd bet that unless you have access to the firmware for those other devices, you wonât be able to control that, because that would circumvent any âsecurityâ CRLâs would give.
Iâd assume that your only real bet would be to hope the oss community has enough invested in the same device(s) you do and figure out how to create custom firmware for them.
If the firmware is encrypted and secure boot is used a MCU (for example common espressifâs ESPâs) canât be flashed (technically it can, but it canât start because of secure boot). Both of these âsettingsâ seem common for matter devices and are also outlined as best practice while not strictly necessary for certification.
It seems matter devices where never mend to be owned
Just curious: Does OHF have a seat at the Matter table?
If so, what is the opinion of their representative? Has anyone fought for local control, right to repair or whatever else you want to call it? How did those discussions go? Is there any hope the manufacturers wonât double down on this and retain control?
It would be nice to know now whether we should even consider Matter for our future purchases.
Also planned obsolescence seems to be a key feature in modern tech.
Wonder if manufactures of certified matter devices actually need to re-new the certificates manually or if it is an automatic process.
Probably didnât and will never happen. Their is Amazon, Google, Apple, Samsung and other big players* on the table which set the rules. Top priority seems like to protect walled gardens which seem to have worked out just a treat
I presume this affects the OEM matter controllers in the market. But in case of an OpenSource Matter server can you not add your own Certificates or readd a revoked cert?
CSA is claiming revocation is necessary to ensure âgenuineâ matter devices and not forgeries, i.e. mis-branded products or, more likely, products that did not pay the certification fees. So partly this is to protect users, but mostly to protect their revenue.
One scenario where revocation does come in handy is if a vendor or developer âgoes rogueâ â or gets hacked â and a firmware update includes dangerous malware. By revoking the cert, owners get a warning that something is wrong, until the vendor repairs the problem and a new cert is issued.
Note this is the same strategy Apple and Google use to protect their phone users from malware â and, yes, guard their App Store revenue â and literally billions of people are ok with it. Those who object can buy alternative phones.
So it is the userâs responsibility to decide, and the device can still operate, so calling this a âkill switchâ strikes me as fear-mongering.
Also note itâs the commissioner that checks periodically for CRL, not the device itself. Your suggestion that the device is going online is intentionally misleading.
I do take issue with the secure boot, and I hope the community can help identify any device that chooses to implement this optional âfeatureâ so we can purchase accordingly.
it still can operate âlimitedâ whatever that means
How would Peter call this? I can change the title to your liking to donât scare anyone!
Did I suggest this? Afaik most (not all) matter devices are happy with a local ipv6 for communicationâŠ
Some matter devices (allowed by specification!) only offer full functionality if connected to some ones cloud
(Function Chart for Sonoff Matter certified Device)
For now, not one successfully matter certified device was freed afaik. The highest chances at the moment seems to be a Shelly 1PM Gen4 according this thread (should allow flashing own firmware via browser).
The mentioned Sonoff mini D on the other hand is not freeable due to secure boot and disabled download mode )
This is disappointing. With all the hype Iâve read here, and all the effort NC and the HA development team are putting into Matter, I sort of assumed it was a good thing for local control.
Shouldnât we collectively be pushing back against this sort of thing, rather than embracing it, putting development resources toward it, and singing its praises in official HA blogs and announcements?
Steering users down the path of a walled garden solution seems to obviate the need for something like HA in the marketplace.
To my understanding, the revoked certificate acts more like a recommendation to reject the device. The Matter controller (e.g., Apple Home or Google Home, in our case Home Assistant) can decide what to do with this information. So Home Assistant can easily add an âunsafe modeâ where a revoked certificate can be ignored. As others pointed out, this is already possible with some sophisticated workarounds (see this thread).
So, of course, the whole certification revocation sounds a bit alarming, but for us HA users, it should not be an issue.
People who rely on a closed ecosystem like Apple or Google on the other hand, can get their devices bricked (at least from their perspective).
I hope not. Iâm still not 100% clear on what the below means.
It reads like lack of a cloud connection can âlimitâ the functionality of the device. In other words, manufacturers could use this limitation to curtail all the most important functionality outside their walled garden. And if they can do it, I think itâs safe to assume they will.
Call me a cynic, but to me this talk about âcertificationâ sounds like a way to force users into a paid subscription model.
This is really no different than current browser/cert model.
People go to 3rd party whoâs is authorized issuer of certs. Browsers/OS add cert authorities to list. When you connect to site cert is verified as not expired and issuing authority checked on list. Authority can ârevokeâ certs at any time for various reasons. Browser shows warning if cert is no good and user can bypass warning.
Yes. Depending on the hub/server/device this can be a lock-in mechanism but that requires cloud connection . If your device requires 3rd party cloud connection you should expect changes to function at any time.
I think thereâs a difference between a web site requiring a signed certificate to use SSL and a device like weâre talking here.
Yes, sometimes I want to know that Iâm connecting to the back end server Iâve selected, and that data moving between my browser and that server is encrypted.
However, a device Iâve installed in my own home, to work locally on my own network, has no such requirement.
Sure, as a manufacturer, if itâs going to be using your cloud services, then by all means, authenticate it to verify itâs legit and not compromised. And if you donât like the connection from a device, for any reason, then feel free to just ignore it.
But it seems thereâs more to it than that. It seems like a framework is being built which can prohibit the device from even being installed and used locally without approval from a back-end server. Beyond that, there is language which suggests the device can even be disabled, or limited in functionality, by the manufacturer at any time, for any reason. Such as, say, the customer stopped paying their subscription fee.
Iâm not saying this is the only use of this framework, or that any particular manufacturer is doing this today.
But weâve all seen this before. If the capability exists, it will be exploited. When the only goal is increasing share price, it would be irresponsible of a corporation not to take advantage of this revenue stream.
Unlike for Zigbee, ZWave or ESPHome this actually seems to be true for Matter devices. Not only that full functionality of a Matter certified device can directly depend on cloud/app/account
But the initial commissioning (before being able to make any use of a matter device) requires cloud to allow provisioning. That part might be circumvent as described here: Guide: Bypass matter attestation verifier
I expect the default matter Implementation shipped wit HA to actually ârespectâ the DCL because otherwise they would violate the matter specification?
Linux users on the other hand have no automatic cloud backup and if they donât take care of some backup they might loose access in case of an incident 
I can change the title to your liking to donât scare anyone!
)
