Matter - smart home connectivity standard (formerly Project CHIP)

Ah: that’s make much more sense.

I’d taken Wi-Fi routers as creating a LAN, but should’ve written Thread devices creating a local network–instead of border routers which actually connect two LANs: Wi-Fi and Thread–is that more accurate?

Thank you for sharing about the ZigBee Light Link protocol. That is really insightful to read. I think you’ve hit the nail on the head: the definitions of “controllers” seems very, very similar between the two, as does the optional internet/cloud-based control (page 21).
//

Citing complexity, Matter smart home standard delayed again - Stacey on IoT | Internet of Things news and analysis

But for the big smart home players, Matter is already in their rear-view mirror as they build services reliant on devices that aren’t even part of the Matter spec. This isn’t to say that I think Matter is no longer important, but that any company betting on Matter as part of their business strategy needs to understand the role it’s likely to play.

This part did not quite make sense. Matter was meant to mainly connect most devices, but there was always space for software & hardware innovation that gets pushed in Matter 2.0, Matter 3.0, etc. Matter doesn’t seem to be a very static standard, but one that follows the industry (perhaps because it is made up of the industry?).

Less like the Z-Wave Alliance and more like JEDEC?

JEDEC is the one industry body that standardizes DRAM. It’s independent, but its major members are the Big Three DRAM manufacturers: Samsung, SK Hynix, and Crucial.

JEDEC is often meant only to standardize the innovations created by the R&D departments at Samsung, SK Hynix, and Crucial so that we don’t have “Samsung LPPDR4” and “SK Hynix LPDDR4”, but just LPDDR4 made by SK Hynix or Samsung.

Samsung, SK Hynix, and Micron push the boundaries with faster & more dense & quicker DRAM and then later, JEDEC compiles those proprietary improvements into a universal standard: LPDDR4X, GDDR5X, etc. That way, when any OEM buys LPDDR4X (even if it was, say, pioneered by Samsung), they buy the JEDEC standardized version:

Mediatek & Samsung jointly launch the first mobile phone with LPDDR4X in February 2016.

JEDEC released the LPDDR4X specification in March 2017.

/off-topic-example-aside

//

From the /r/smartthings subreddit, someone noticed Aeotec recently confirmed to Tom’s Guide that their hub will support Matter, but that’s as much as they said.

Like the SmartThings hub, the Aeotec hub will work with Zigbee, Z-Wave and Wi-Fi smart home devices. A company representative also said that it will work with Matter when that smart home standard becomes available.

Yes, that sounds right. You don’t need a border router to have a thread Network, but by adding a way to get to Wi-Fi you add a way to get to the Internet.

I had the same reaction that you did. Normally I’m very impressed with Stacey’s knowledge of the IOT industry, but on this particular point, I think she was just incorrect.

The big push for matter with Amazon was their desire to stop having to explain to customers why they had bought something that then didn’t work with what they already had. And in particular, both Amazon and Apple agreed that it should be possible to come up with a standard so that the same third-party lightbulb/smart plug could work with either HomeKit or Alexa. Or even both at once.

Both of those motivating factors still exist, so I’m not really sure what she’s thinking of in that particular article.

1 Like

Since Samsung is providing the firmware for the Aeotec WASH hub, as well as the app, I would expect Aeotec to be dependent on smartthings’ implementation of Matter. :thinking:

1 Like

Matter is “Open Thread”, i.e. 6lowpan. Thread border routers require IPv6 in order to interoperate, either by functionality which does not exist in home routers/residential providers, or by exploiting the lack of basic secured IPv6 networking.

For instance, if you look at Open Thread’s documentation for border routers it states up front that it will not work if basic IPv6 security features like RA guard have been deployed.

Amazon, Apple, Google, etc… do you expect them to tell consumers to permanently disable IPv6 security on their home networks?

On the flip side, can you imagine the effort in educating network providers/having them deploy, IPv6 in manner it was designed? Here in the US, as an example, Xfinity/Comcast only provide /60 prefixes to business customers, by RFC they should be providing /56 ( or /48 ). What CenturyLink’s has deployed as IPv6 is pretty marginal.

And if the network providers suddenly fixed their IPv6 deployments? I don’t believe that any home, or for that matter many “enterprise” routers, support providing prefix delegation. Providing ipv6 prefix in a secure manner is not a well documented subject.

These are just a sample of the problems that come up with interoperability, a complete list of issues would be substantially longer.

RA Guard is already typically disabled by default on network routers sold for home use because it prevents auto discovery. TP Link doesn’t even offer it on most of its home models. It’s only considered “basic IPv6 security” for enterprise level systems with lots of users, most commonly college campuses or some commercial prime targets. Its main purpose is to prevent Denial of Service attacks that flood a network or, to be honest even more commonly, human error that misconfigured a device being added to a large network.

It’s one of those things where theoretically there might be an issue for an individual private person, but the odds of that kind of home being the target of such an attack are really really small.

The following references are super technical, but may be of interest in discussing this issue:

.

https://arubanetworkskb.secure.force.com/pkb/articles/HowTo/What-is-the-prevention-mechanism-against-Rogue-Router-Advertisement-attack-in-an-Aruba-Mobility-Access-Switch-Environment
.

.
As far as Matter itself, it utilizes a multilayer approach to help prevent Denial of Service attacks, including identity verification. These look to be sufficient for a typical home environment.

There’s a lot of analysis available regarding Matter and security, but I haven’t seen any raising any particular alarms of the kind you’ve brought up. Maybe I missed it. Anyway, most industry analysts seem to think it will be at least as secure as HomeKit, which is decent for a home environment.

Here’s the official Matter whitepaper just as a place to start.

And for something more technical, Matter is planning to use blockchain for device identity verification, a technology used almost exclusively for cryptocurrency when RA Guard was introduced, but now finding a place in other security use cases, including IOT.

1 Like

How do you come to the conclusion that features like RA Guard, or its equivalent, is only relevant to enterprise networks?

That conclusion ignores any number of security exploits that occur in the home environment.

I do not follow how a lack of a feature in some vendors routers/switches means that exploits do not exist ( FWIW a lack of RA Guard probably points to a lack of ACL in the network fabric ). And as I mentioned, this is not only feature missing that openthread border routers look for that is currently missing in IPv6 home networking environments.

As for the White Paper you point to, it is long on buzzwords and short on details. Take the word “blockchain”, it references an article that discusses a lack of substance in how the word “blockchain” was used in reference to Matter. Ask yourself this about the White Paper, do you really think that in just nine pages was created to answer how Matter is secure, or was it written for journalists to re-spin as an article?

I’m sure you’re right: as I said, that one was just a place to start. But it does indicate a direction. “Blockchain” is not a buzzword: it’s a specific technology. (Just as “smart home” is a buzzword, but “Zwave” is not.) As to how Matter intends to use that technology, there’s a bit more detail in the next link I gave. It will be a public ledger to assure the authenticity of devices joining the network. That’s both new and interesting. But of course we’ll have to see how it all plays out in practice. :thinking:

1 Like

Blockchain is most definitely a buzzword, Google it :slight_smile:

If you boil down what has been presented on Matter, what is being talked about is signing the firmware for devices using blockchain ( which is a gimmick ). Simply signing firmware is not enough, in and of itself, to build a secure device. Most devices are built using different components which, each having their own firmware. You have to check each of these in a secure manner as the device boots.

Z-wave as a buzzword? Silicon Labs would probably love for it to be a buzzword.

Some reading material may fill in the gaps (some that nobody has publicly filled), but I also don’t understand the complete argument.

It’s not a signature check for booting (that’d be trivial; no need “blockchain”), but more a database of metadata for each device:

Measured boot / firmware tests is only “recommended” and not required, while Matter’s DCL (Distributed Compliance Ledger) is a requirement.

The questions I have:

  1. Why not just use a traditional CSA-managed database, a la USB-IF, for certified devices instead of a blockchain database?

The main answers posited by CSA seems to be the 1) size, 2) attesting genuineness + OTA updates, and 3) reliability.

In addition, Matter adopts the very strong concept of device attestation that implements the core concept that a Matter device cannot join a Matter fabric unless proven genuine.

With potentially billions–if current estimates are to be believed–of new Matter devices expected to be commissioned in a short period of years, attesting each unique device’s genuineness + OTA version + ongoing Matter compliance does not sound cheap to scale, if each Matter commissioning device needs to access the DCL each time it commissions a new device.

And, the reliability & security of the database: it’d always be tough to scale & secure with just one entity as the central hub that commissioned devices globally. Some decentralization was probably required from the get-go.

I don’t pretend to understand blockchain beyond this, but as a difficult-to-modify, decentralized database to securely attest + monitor + detail billions of devices, the DCL does seem OK.

  1. Why even incorporate a cloud connection (e.g., to commission devices) to a local-first protocol? Seems like another point of failure.

As far as I can tell, the OTA check is only a periodic (but how long is a cycle?).

I do respect the decision that some periodic OTA updates & firmware checks are required for IoT to ever scale without inadvertently creating billion-large botnets. Trying to be “100% local” works for enthusiasts (well, until the day we don’t do 100% local and now, decades-old firmwares on decades-old-devices are now suddenly visible to the world), but a black-and-white firewall is not sustainable for consumers that actually want just some cloud connections (e.g., out of home alerts for smoke detectors, third-party weather automations, etc.).

1 Like
1 Like

Not mentioned in the article, but in the same announcement: Meross has also joined. :sunglasses:

2 Likes

Broadlink, Hisense and Intel, too.

3 Likes

I have been told by another source that broadlink is initially only going to look at matter compatibility for their smart bulbs and switches. Not the RM series. It’s always good to have more choices, but that’s a pretty crowded device class already.

2 Likes

Hmmmm…

A friend of mine asked me if they don’t have a smartthings hub, a Samsung smart television, a Samsung smart refrigerator, or a Galaxy phone, but they do have a different android phone and a smartthings account, will their Matter devices show up in the smartthings app? That is, they don’t have anything on their smartthings account that would act as a Matter hub. So who talks to the Thread devices?

I’m guessing… Nobody. That is, I think, the Matter devices might not show up. :thinking:. Anybody know otherwise?

@Automated_House @jkp @jody.albritton

2 Likes

That’s a good question. Espressif’s Matter blog seems to confirm that “Matter Thread” devices will be in a separate, isolated sub-network.

In a nutshell, Threadis an IPv6-based , low-power, mesh networking protocol for Internet of things (IoT) products. It is built on IEEE-802.15.4 technology, so the Thread devices cannot communicate with the Wi-Fi or Ethernet devices directly. In the Matter topology,a special device is required to connect the sub-networks, the device is called the Thread Border Router (Thread BR will be used for short).

With that very problem in mind, how CSA is going to market “Matter devices” when half use Wi-Fi and the other half use Thread.

  • Matter Wi-Fi devices need proximity to a Wi-Fi access point; Matter Thread devices do not.
  • Matter Thread devices are mesh-capable; Matter Wi-Fi devices are not
  • Matter Thread is isolated without a Thread Border Router

My assumption to this certainly large problem is that CSA assumes people will “stumble” onto a Thread Border Router (which is, tbf, not a great name for typical users) in a HomePod or a Nanoleaf light or, likely ideally in some # of years, a Wi-Fi access point that doubles as a Thread border router.

I don’t think that’s a good game plan at all, though. I can’t imagine trying to explain “No, you have a Wi-Fi router that works with some Matter devices. Now you need a Thread Border Router to work with other Matter devices. Yes, they’re both Matter. Yes, they’re both called routers. No, it’s a different network. No, it’s not the same as Wi-Fi mesh: it’s a Thread-only mesh. No, not a Matter mesh: Matter isn’t mesh. It’s just the application. A Thread mesh. Yeah, it’s a ‘Matter Thread’ device.” /s (only half-joking)

3 Likes

Of course, this is exactly what we have to explain to new smartthings users now. :wink:

But, yes, I agree. Systems which require a device which is a thread border router before you can create your first automation, like HomeKit, won’t have any issue. The first thing you get enables all the other things. Same with an Aqara hub. And IKEA’s new Dirigera hub. As well as some of the Amazon Echo models. So their customers are not going to run into this. If I understand the Google announcement, at least some of their nest speakers or whatever they’re calling their smart speakers these days will also be thread border routers. And of course a few of the newest WiFi routers like eero and Xfinity are going to include a built-in thread border router as well.

I suspect Samsung Will handle it by saying you need to have a smartthings “hub“ (which could be a smart television) in order to use matter at all. Of course we’re tripping over the Terminology again, because the smartthings “hub” is not going to be a “matter hub.” (It’s going to be a “matter bridge.“) But it is probably going to be a hub that you need if you want to use matter. :exploding_head:

All of which is to say I suspect it’s going to be pretty rare for someone to have a matter set up which only works with Wi-Fi, because most of the apps which work with matter are going to require a device which is a thread border router. But we will have to see.

3 Likes
1 Like

Very interesting, thanks for sharing!

You should also create a thread for this article under General and tag it iotindustry . Even community members who aren’t very interested in Matter yet should find this interesting just from an ST perspective. :sunglasses:

2 Likes

Most interesting to me:

  1. a hint of future Thread support.
  2. confirmation that zwave and zigbee devices will not be exposed to other Matter controllers. Neither will Samsung appliances.
3 Likes

Also confirmation that they aren’t planning on zwave for the tv dongle, just Zigbee.

3 Likes