On a recent Internet of Things Podcast episode, we took a question from our Voicemail hotline from Greg. He’s asking how Matter handles IoT device security, which is a great question. It’s also a timely one as we expect to see Matter-certified device availability soon. And thankfully, the Matter specification does provide universal, robust security requirements in order for device makers to have that Matter certification logo on their products.
Stacey recently covered the pros and cons of Matter’s security implementation, but I’ll recap them here.
First, the Matter standard requires that device data is encrypted as it travels along the home network between devices. The Advanced Encryption Standard, or AES, must be used for this. That’s a positive step although it doesn’t quite go far enough. Matter doesn’t require encryption for device data once it leaves your Matter network over Thread or Wi-Fi. Obviously, manufacturers can include that data encryption if they want to, but they’re not required to for Matter devices.
Second, all Matter-certified devices must be capable of accepting OTA, or over-the-air software updates. This is important to get security patches out to a massive number of devices quickly and easily. Device makers aren’t required to patch infected devices as part of the Matter standard, but I suspect most will do so anyway. If not, they run the risk of bad publicity, which can negatively impact future device sales.
The CSA also recommends that Matter devices include a secure enclave on board. This is a secured area where private data is stored and only accessible to the device. Think of it like the secure enclave that Apple uses to store biometric and digital wallet information on its iOS devices. Additionally, all Matter devices must use public key encryption and certificates to guarantee their identity. This approach is similar to websites using certificates to tell users “yes, this is the website that you navigated to at this URL address.” A rogue, non-Matter device can’t “spoof” a certified device, for instance. Certificates can be issued from either DigiCert or StrongKey, or a manufacturer can generate their own device certificate for this purpose.
Speaking of those certificates, which are called Device Attestation Certificates (DAC), the certs are checked before your Matter device is onboarded to your home network. And all of these DACs are registered in a distributed blockchain ledger so there’s a record of them. Any new Matter device you add to your smart home will check the device certificate against this ledger for authenticity.
While there are still a few ways Matter device security could be beefed up, this first release is fairly solid. I feel more comfortable putting Matter devices in my home than I do compared to older, non-Matter products. Some of this security model comes from Apple’s HomeKit implementation, which, again, brings me a relatively high comfort level.
To hear Greg’s question in full, as well as our discussion on the topic, tune in to the Internet of Things Podcast below:
Updated: This story was corrected to note that Matter does not require a secure enclave on devices, simply recommends it.
User data will be exfiltrated securely, I guess. The big issue is what data is being collected/transferred over the network and how users can control that data. Not how to manage what devices are on a network (which is an issue, but not the hard one).
James Alexander says
Unfortunately, I do not believe that a secure enclave is a requirement of the Matter standard. I recommend reading chapter 13.6, which clearly states that hardware protection of private keys is optional. Given this wiggle room intended to allow very low-end microcontroller-based devices to participate in the standard, I was hoping that there was at least a way to differentiate devices lacking secure storage capability so that network admins can make a choice to not trust such devices, but I cannot find anything in the standard that could be used to build such an admission control. i welcome any corrections to my understanding of the spec.
Stacey Higginbotham says
you’re right. It is recommended,, not required. I was given wrong info initially and will change this.