Emerging in IoT: Why Does It MATTER?

Why are standards important in cybersecurity? And why are there so many? Often we might tell ourselves that we have to apply standards to anything cybersecurity-related, especially if, as an industry, we want to defeat the attackers. 

Most cybersecurity standards come out of a specific industry, and each industry likely has more than one. The FDA will soon have statutory authority over medical device cybersecurity requirements, for example. 

The automotive sector’s cyber standard in Europe is largely influenced by UN Regulation 155 and in the U.S., we use ISO/SAE 21434, which isn’t as prescriptive as 155. And we could drone on about standards in a litany of other industries. 

But what about the devices that power our daily lives? What about the average person who uses connected devices without even thinking about their “connectedness”? Consider: vehicle entertainment and safety systems. Health and personal statistics tracking. Smart appliances. Smart in-home systems for heating and cooling. Smart speakers. 

The average number of IoT devices per household sits at 22 and 5G availability is boosting usage beyond the estimated 14.4 billion devices in use worldwide this year. 

But back to security - are these devices really smart if they are so vulnerable? The average IoT device user likely doesn’t know much, or even care about security. After all, it's typically assumed that if you use a device, it's just ready for use. 

However, for anyone in product security, or more broadly in the AppSec discipline, we know this is not the case, regardless of how much security is built into any AppSec or product security phase, and even after products ship. Standards are essential and they can make or break a connected product’s performance, security and revenue. 

XIoT (Extended Internet of Things) technology, or the extension and pervasiveness of IoT devices requires an alignment on security standards. In order to keep in step with the pace of XIoT, security protocols need to evolve so that security becomes easier and more automated. 

The Matter Standard

The New Matter IoT Protocol is a set of standards developed as part of Project Connected Home Over IP (Project Chip) in 2019; however, the Connectivity Standards Alliance (CSA), formerly known as the Zigbee Alliance, serve as the protocol's current maintainers and developers. As an attempt to encourage adoption to deliver interoperability between devices and platforms, the Matter standard is royalty-free.

Specifically looking at XIoT technology, the focus has begun to shift to security balanced with the ease of use and installation. This is where the new Matter protocol attempts to excel, implementing a balance of security and ease of initial setup and use. To these aims, Matter largely succeeds.

As with any new technology, there are bound to be a few hiccups along the way. In this article, we'll take a closer look at some potential points of failure in the Matter IoT protocol implementation, and explore how these challenges can be overcome.

The current state of XIoT connectivity leaves much to be desired from an interoperability standpoint, with multiple manufacturer ecosystems, multiple communications protocols, and even different security methods for adding new devices and daily operation. From a consumer perspective, use of the various ecosystems becomes confusing, hard to navigate, and non-intuitive to set up. For a manufacturer, the need to support all available protocols adds additional complexity to initial development efforts, as well additional effort in coordinating and providing ongoing support and software upgrades/patches.

With the ease of use of XioT devices built according to the Matter protocol, many of the former complexities are reduced. Matter-enabled devices become easier to adopt, and can operate within multiple ecosystems with ease, all with the same level of security. With one standard, manufacturers can more easily support multiple ecosystems with limited development effort, and reduce the overall cost of ongoing maintenance, while maintaining a level of security.

With all the improvements that Matter can deliver for both the consumer and manufacturer alike, it can also have drawbacks. With mass adoption of a new protocol that touts a “secure by design” approach to its implementation, adversaries will often see this claim as a challenge to break it. Should issues in implementation of the Matter protocol itself be discovered, in what is a new market, with few “real-world” applications, these new discoveries have the potential to affect every device in which Matter was developed. We’ve seen these issues in the past with other standard communications methods in XIoT: vulnerabilities in the underlying 802.11 protocol for WiFi, BLE communication security failures, and even similar issues with Zigbee and Z-Wave, introduced significant risks to the devices, and the networks in which they were deployed. It hasn't happened yet, but in time, Matter will also likely be subject to similar failures.

What Is Matter?

Matter was officially launched in late 2022 with many XIoT device manufacturers promising implementation into Q1 and Q2 of 2023. A limited subset of manufacturers and their devices were available as early as December 2022.

Matter is designed to provide end-to-end security for IoT devices, including device authentication, secure data transfer, and secure device management. The protocol is intended to be used by manufacturers and developers of IoT devices to ensure that their products are secure and to help organizations that are deploying IoT devices to secure their XIoT networks and protect against cyber threats.

Why Consider Matter in the Security Ecosystem?

• New network entry point
• Expected massive adoption
• Wireless
• Remote access
• Remote attacks
• Observable traffic from a distance

Chipset Manufacturer Support

The Matter protocol is based in part on the Zigbee standard, and as such, it is supported by many Zigbee-compliant chipset manufacturers. These manufacturers include: 

• Texas Instruments (TI)
• Silicon Labs
• NXP Semiconductors
• Broadcom
• Marvell
• Cypress Semiconductor
• STMicroelectronics
• Renesas Electronics
• Bouffalo Lab
• Realtek
• Espressif
• Telink

It is worth noting that not all chipsets from these manufacturers support the Matter protocol, and it's important to check the specifications before purchasing a chipset to ensure that it is compatible. Additionally, not all XIoT devices that use Zigbee chipsets are supported by the Matter protocol; it's important to check the manufacturer's documentation to confirm if the device is Matter protocol- compatible.

Finally, Matter is implemented at a higher layer in the protocol stack, and is not dependent on Zigbee. To commission a Matter device, it needs to join an existing IP network. The IP network can be implemented over Bluetooth Low Energy (BLE), WiFi, and even Ethernet. At time of this writing, much of the Matter implementation is seen over BLE and WiFi, with a push to implement over Thread (a new IoT communication protocol designed to enable interoperability and connectivity between smart devices from different manufacturers).

Security Implementation: Commissioning and Operation

The Matter protocol uses a secure method for integrating new devices into an IoT network called "Commissioning." This process is used to securely add new devices to an existing network, and it involves several steps to ensure that only authorized devices can join the network.

Each device is issued a unique digital certificate that contains its public key and other identifying information. The certificate is generated during the device manufacturing process, typically by a trusted third-party certificate authority (CA).

The process for generating the device certificate typically involves the following steps:

1. The device manufacturer generates a public-private key pair for the device during the manufacturing process, with data derived from a hardware-based random number generator (RNG).
2. The manufacturer then sends a certificate-signing request (CSR) to a trusted third-party certificate authority (CA) that is authorized to issue certificates for Matter devices.
3. The CA verifies the identity of the device manufacturer and the information provided in the CSR. If everything checks out, the CA issues a digital certificate for the device, signed using the CA's private key.
4. The device manufacturer then installs the digital certificate and private key in a secure location on the device, such as a hardware security module (HSM) or a secure element (SE). This private key can also be stored on “disk” outside of a secure element.

When a device attempts to join a Matter network, it presents its certificate to the network coordinator/commissioning authority, which can be a dedicated device or a group of devices.  The network coordinator/commissioning authority then verifies the certificate's signature and other details to ensure that the device is legitimate. The commissioning request is broadcasted to all devices in the network. The verification process typically involves the following steps:

1. The network coordinator checks that the certificate was issued by a trusted CA and that it has not been revoked.
2. The coordinator checks that the public key in the certificate matches the public key presented by the device during the authentication process.
3. The coordinator checks that the device is authorized to join the network based on the information in the certificate, which includes the device's identity information, such as its MAC address, and a digital signature created using the device's private key (derived from some unique input, including a 27-bit PIN). The commissioning request is verified by checking the digital signature against the device's identity information to validate if the device is authorized. If the signature is valid, the commissioning authority sends an acceptance message to the new device, which includes a network key and a network address.

If the verification process is successful, the device is allowed to join the network. If the verification process fails, the device is rejected and cannot join the network. The new device then uses the network key to encrypt all future communication with the network and uses the network address to identify itself to other devices on the network.

This process ensures that only authorized devices can join the network and it adds an extra layer of security to the network. Additionally, the new device should be able to validate the network key and the network address to confirm they are coming from a trusted source.

{{cta('186741546866')}}

Where Matter Security Can Fail

My review of the Matter protocol specification document inticates to me that the CSA has done a thorough job evaluating potential security implications, including specific enhancements for software component validation. I have used the quote “Those who fail to learn from history are condemned to repeat it” from Winston Churchill (and more appropriately, George Santayana) many times over the years. I see many security failures in protocols in use in XIoT, that when developed, do not consider failures discovered in the past. In this particular case, it is my opinion that the CSA has taken a history of failures into consideration, and attempted to improve on existing security posture!

No matter how carefully a protocol developer tries to ensure the overall lack of security issues, failures can come down to how the protocols are actually implemented in any given device or XIoT solution. This is where I expect many of the initial failures to be discovered; poor implementation of the Matter specification, as opposed to Matter design flaws.

Default PINs

Static authentication PINs preinstalled on an IoT device by the manufacturer can compromise security because they are easily discoverable and predictable. If the PIN is hardcoded into the device's firmware, it can be discovered through reverse engineering or other means. Additionally, if the PIN is the same for every device or a small set of devices, attackers can easily guess or brute force the code, gaining unauthorized access to the device. 

Should a PIN be used as input to other cryptographic actions, once known, the knowledge of the PINs significantly reduces the overall entropy of the solution, potentially allowing for recovery of cryptographic material. Knowledge of default pins, if used as part of an authentication process, effectively makes any benefit from that authentication process null and void.

Default Device Key/Certificates

It should not be possible to generate default keys for a device based on the Matter specification as they should require unique hardware addresses to accomplish initial key generation, tied to public and private keypairs generated at time of manufacture. In this case, the MAC address of a device is not used in the authentication process, so spoofing the MAC address of a new device would not enable an attacker to bypass the authentication process. In fact, the Matter protocol is designed to prevent this type of attack by using secure communication protocols and cryptographic mechanisms to protect the integrity of the authentication process 

However, certificates used for authentication, operation, and even device and firmware attestation have more likelihood of being pre-calculated and stored on a device, or within default firmware. This is a common problem for web-based interfaces on XIoT devices, especially where a certificate chain of trust must be maintained.

This becomes an issue when, in order to maintain that appropriate trust, certificates and key material must be signed by an appropriate authority already trusted by the solution or end user. Ultimately, the signing/generation mechanism cannot be distributed to generate appropriate material at boot, it must be done during the software development lifecycle

Thus, the subsequent risks of having pre-generated, default public key cryptography keys stored on a device are:

• Vulnerability to hacking: If attackers know the default keys, they can easily crack the encryption and access sensitive information.
• Lack of uniqueness: Having the same default key/certificate across multiple devices can result in key reuse and weaken security.
• Predictability: The use of predefined key/certificate material makes it easier for attackers to predict the key and crack the encryption.
• No control over key/certificate management: Pre-generated keys/certificates may not be managed properly, resulting in loss of control over key/certificate usage and distribution.

RNG Failures

A problematic RNG (Random Number Generator) implementation can significantly impact the security of cryptographic functions. Cryptographic functions rely on a secure and unpredictable source of random numbers for key generation, encryption, and decryption. If the RNG is predictable or biased, it can allow attackers to guess the generated key or crack the encryption, compromising the confidentiality, integrity, and authenticity of the data. Therefore, it is crucial to implement a secure RNG and regularly test it for vulnerabilities.

Checking for predictable RNGs can be difficult for several reasons:

• Complexity: RNG algorithms can be complex, making it challenging to determine if the output is truly random.
• Hidden biases: Some biases in RNGs may not be immediately visible and can only be detected through extensive testing and analysis.
• Unpredictable nature of randomness: The unpredictability of randomness makes it difficult to determine if an RNG is truly random without performing multiple tests over a large sample size.
• Variability: Different types of cryptographic functions have different requirements for randomness, making it challenging to develop a single test that can effectively detect all potential biases.

In summary, checking for predictable RNGs requires a deep understanding of the RNG algorithm, statistical analysis, and a large amount of computational resources to test over a sufficient sample size.

Where Finite State Can Help

As of this writing, the Matter protocol appears to be well thought out, with significant consideration regarding the implementation of authentication and authorization techniques.  Implementing Matter in XIoT devices, following the specification documentation can help overcome the common pitfalls around default credentials, improperly stored certificates, and even detection in poor development processes for RNGs. However, there will be occasions where developers implement Matter in ways that don’t quite meet the specifications or other requirements.

Using our advanced firmware analysis techniques, it Is possible to detect many of the common failures indicated in Matter protocol implementations today, including:

• Hard-Coded Credentials and PINs through detailed configuration analysis
• Detection Common protocol implementations from several manufacturers, and open source projects including their versions and potential code forks
• Certificates and key material, default or pre-populated in firmware images
• Unsafe function calls, analyzing them for previously unknown exploit conditions through advanced Common Weakness Enumeration (CWE) observation and data flow analysis.
• Software component identification and version in support of Software Bill of Materials (SBOM) generation