Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Can anyone here confirm that Matter/Thread will be a bright, open, and happy new future?

Sorry, it’s a closed ecosystem. It relies on PKI and device attestation to ensure that only devices from approved partners are usable. It’s unlikely that small players can participate, and zero chance of any homebrew scene.






I disagree that there’s zero chance for a homebrew scheme; it’s pretty easy to enable development mode and commission self-made devices using Google Home or Apple Home on both iOS and Android.

Dev mode seems like such a nonstarter. I don't know what dev mode entails, but I don't want to be running my kitchen light in dev mode, I'll just use an analog switch.

> Dev mode seems like such a nonstarter. I don't know what dev mode entails,

... what?

All it means is that the "commissioner" (broker which attaches Matter devices to your Fabric) ignores the chaining of the device attestation to an approved CA. In the case of using Google's Commissioner, this requires adding a Vendor and Product ID in your account's Developer console. In the case of Apple's Commissioner, it's just pressing a "Trust this unknown device" button. That's it.


I can't conceptualize exactly what the use case is here, but I get the impression there's a set of steps that have to be done in sequence after installing my light bulb, and that's another step to an already fairly involved process. All to screw in a light bulb. And the light bulb is the easy case. If it's actually two devices and I want them to talk to each other, and one of them is automatically trusted, and the other one is untrusted, I'm skeptical that just pushing the button is going to help. (Actually in general I'm skeptical that it will typically work without extensive research, and this is just one in a long list of potential gotchas.)

And manufacturers tend to lock down their Matter devices, too, so you can't flash Tasmota or ESPHome on them. See: Shelly, Sonoff.

Not just tend to, have to. Matter certification requires flash encryption and FW signing.

Are these requirements public?

I was working on a Matter device but it never got certified due to high cost/lack of customer demand.


Matter specifies that all firmware images must be signed so the device can verify authenticity before installation, ensuring they haven’t been tampered with. Matter further requires mechanisms to prevent unauthorized firmware execution and ensure that firmware can't be downgraded.

Matter states that firmware images “may be encrypted.” This is not a requirement, though encryption is allowed and may add security

(https://community.arm.com/arm-community-blogs/b/internet-of-...)


This sounds like it only affects OTA updates going through the Matter stack, not an explicit requirement to block serial flashing.

Disclaimer: I haven't tried serial flashing of Shelly/Sonoff Matter-enabled devices myself, just remember some complaints of customers that failed to re-flash such devices.


You say that as if that’s a bad thing. I would love to have more iot security

where "security" here means "anything not explicitly sanctioned by the vendor is prohibited"?

No it means signed firmware and verified boot…

That's pretty far from the main issue with iot security, and a heck of a lot of the issue with IoT in general, that the hardware gets vendor locked to a vendor that stops supporting the software (and wasn't very good at writing it in the first place)

What? You can buy a very cheap ESP32 with Thread and easily build your own device with Matter/Thread and it will work. Doesn't seem that closed. There is OpenThread that is an open source implementation of Thread. Home Assistant is compatible with Matter over Thread devices... What's closed about this?

You can’t talk to other devices unless you got the private key of them.

> You can’t talk to other devices unless you got the private key of them

can you explain what you mean by this?


Buy a device from the manufacturer “Eve” try to add it to homeassistant after upgrading its firmware to use matter/thread: no can do, they don’t give you their key to talk to their devices.

I did exactly this. Got an Eve smart plug meter and it works flawlessly in HomeAssistant. I'm also pretty sure I had upgraded to the latest firmware via Apple Home app before doing so.

They work without issues Ine HomeKit mode. With thread/matter only Apple got the keys or whoever paid them to get them.

Also: the Apple home app can’t change their mode to matter, you have to do that in home assistant.


Great, their new devices actually work in thread mode with HA, but their older ones only when you got an Apple hub device. I’ve got 6-7 of their devices before matter was a thing and 0 work with HA. Even those that got firmware updates.

I know almost nothing about Matter but is this true? I though that if you control your own fabric, you can talk to any device on it because they trust your controller.

This is correct; the hand-wringing in this thread is fair in that Matter does have a central governing authority who determine which devices are trusted, but completely unjustified insofar as that making a DIY Matter fabric/network is extremely easy.

The part about Matter that's "closed" is the device attestation process; the Distributed Compliance Ledger (DCL) contains a closed set of trusted Product Attestation Authorities. The device's Device Attestation Certificate (DAC) needs to chain to these PAAs for a "production" Matter Commissioner to enroll the device in a fabric without additional steps.

Here's he thing: all available Matter Commissioners make it really easy to commission a device with an untrusted DAC; for Google you need to add the IDs for the device to a Developer account associated with device you're trying to use as the Commissioner, and for Apple (at least as of a year or so ago when I last tried this), you just press "Trust this untrustworthy device" on a dialog box.

https://developers.home.google.com/matter/primer/fabric


So it's kinda like UEFI Secure Boot? PKI with a default list of officially trusted companies, and it's supposed to let the end user add their own keys, but the details make people nervous because it would be really easy for the vendor to break that any time they feel like it?

The design is both better and worse:

* The list of officially trusted companies and root certificates is stored on a blockchain, for whatever reason, but at least this way it's a fairly open list and it's supposed to be shared equally across all vendors.

* It's a lot easier to get an official key provisioned / device certified. It's not like UEFI where there's some murky trusted set of root keys belonging to a major manufacturer (Microsoft) who blesses things at a whim.

Importantly:

Even if the "vendor" (in this case, it's Google/Apple) stopped supporting test keys in their Commissioner, one could still run a "fully private" Matter fabric with their own Commissioner. Of course, if this happened, a user couldn't commission their devices onto the walled garden Google Home / Apple Home ecosystems, but, they could still make their own Matter fabric with their own Controller. It's not done this way normally: even with HomeAssistant, which can run its own Matter Controller, the Commissioner role is typically delegated to Apple/Google SDKs through the Home Assistant app. But this is because it's a huge pain to develop a working Commissioner (due to Bluetooth, mostly), not because it's not possible. There's no "lock-out" that causes Matter devices to only provision to approved Controllers/Fabrics - the lock only goes the opposite direction, to prevent end users from buying insecure/spyware devices with the Matter label.

However, unfortunately:

* You don't really enroll your own key or root certificate with most of the "standard" (Apple/Google) Commissioners to use them with development devices - rather, you use a fixed set of vendor or device IDs which signify them as test devices (in the extra easy path, you even use a fixed device certificate for a Test Device). This makes sense from the constraint that users can still build and develop their own devices while protecting the ecosystem from "rogue vendors," but it's not like UEFI Secure Boot in this case where the end user can enroll their own keys and truly control the system end to end.

Now again, there's nothing stopping the end user from building a Commissioner which would trust their own self-signed certificate, besides it being a pain in the butt, but that's not how it works by default - it's truly a development mode, not a bring-your-own-keys.


Z-wave requires certification[1] which includes alliance membership and compliance testing, and there you can do your own stuff using shields or modules[2].

Some manufacturers also make Z-wave devices, like this[3], which has some generic low-voltage inputs and outputs.

So while not as trivial as other things, it's possible to do a lot of DIY stuff.

[1]: https://z-wavealliance.org/development-process-overview-2/

[2]: https://z-uno.z-wave.me/module/

[3]: https://www.fibaro.com/en/products/smart-implant/


> It’s unlikely that small players can participate, and zero chance of any homebrew scene.

I personally think the worst part of this is that China manufacturers are less likely to produce Matter/Thread equipment.

Cheap China equipment has been great for Zigbee adoption. They're much less reliable, but fantastic for getting a smart home going for cheap.


I wouldn't worry too much. Espresiff is going to flood the market with countless units of this chip available for cheap. It can do Zigbee/Thread/BLE.

https://www.espressif.com/en/products/socs/esp32-h2




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: