Blog & News

Table of Contents

1. Introduction
2. Problem Statement
3. Background
   • Supported transports and device types
   • Commissioning and session establishments
   • The Distributed Compliance Ledger (DCL)
4. Common pitfalls and how to avoid them
   • No. 1: Implementing a weak random number generator
   • No. 2: Insufficient protection of the device passcode
   • No. 3: Insecure implementation of the multi-admin and multi-fabrics feature
   • No. 4: Failure to achieve unique identifiers
   • No. 5: Risking access control list wildcards and inconsistencies
   • No. 6: Risks specific to bridges and bridged devices
   • No. 7: Risking privacy by advertising vendor and product identifiers via DNS or Bluetooth
   • No. 8: Risks specific to controllers, commissioners, edge routers, bridges, OTA providers and OTA requestors
   • No. 9: Unsanitized user input
   • No. 10: Rogue commissioners
   • No. 11: Devices may ignore device attestation verification results
   • No. 12: Evil twin attack
   • No. 13: Manipulation of the CommissioningCustomFlowUrl
   • No. 14: HTTP downgrade attack
   • No. 15: Missing minimal requirements for underlying communication channels
   • No. 16: Manipulation of sleepy end device parameters
   • No. 17: Status report message injection
   • No. 18: Revocation from groups
   • No. 19: Underspecification of timed interactions
   • No. 20: Dysfunctional implementations of event logging
5. Conclusion
6. References

Introduction

As the Internet of Things (IoT) continues to grow, the demand for smart home devices that can communicate with one another has increased significantly. The upcoming Matter standard provides a unified and secure approach to connect various smart devices, enabling them to work seamlessly with each other. However, this increased connectivity also means increased exposure to cyber-attacks, which can compromise users' personal information and privacy.

This whitepaper is directed at developers of Matter products and provides a summary of security considerations and pitfalls that should be kept in mind when developing Matter products, based on a security analysis of Matter conducted in a master’s thesis at SCHUTZWERK. Developers of Matter products can adopt these advices to ensure secure and reliable connectivity for their smart home devices. The paper covers security-related topics such commissioning, passcodes, randoms, group communication, bridges and multi-admin. It provides considerations that can be easily overlooked by manufacturers due to the high complexity of the young but promising Matter standard. We expect that readers of this whitepaper have already a basic understanding of Matter. For more technical details, please refer to the full security analysis [1].

Additionally, the paper highlights the importance of secure-by-design device development as well as regularly testing and updating device security measures to keep up with evolving cyber threats.

By adopting the Matter security best practices outlined in this whitepaper, device developers can create smart home devices that are secure, reliable, and trusted by users. The implementation of these practices not only protects users' personal information and privacy but also helps device developers build a positive brand reputation and gain a competitive edge in the IoT market.

Problem Statement

The Matter specification describes an application layer standard that promises security-by-design, interoperability across devices of different manufacturers and improved user experience. Due to the significance of the companies that have already engaged with Matter, we expect Matter to be greatly welcomed and adopted by manufacturers and users in the following years.

Although Matter has been developed with security in mind, and no public vulnerabilities are known so far, a great deal of caution has to be taken when working with young standards. This is because even though they might be robust against many well-known vulnerabilities per design, they have not been as thoroughly tested as market-proven protocols and might therefore contain yet unknown vulnerabilities, whereas older standards offer a better understanding of potential security risks. Even though the Matter functional security is described as self-contained [3], where security measures of the core specification are sufficient to protect devices, and although the specification has been tested for security during development, we were able to identify a handful of risks that can negatively impact the users' security and privacy.

The Matter specification is comprehensive and technical piece of work, that is not understood easily without weeks to months of commitment. There are several security and privacy relevant sections that give developers freedom on how to implement them, which risks manufacturers making mistakes that can lead to vulnerabilities. We expect that many developers, especially smaller development teams, will not be granted the time for fully understanding the Matter specification and its security implications. Therefore, we hereby provide a brief summary of the most significant security considerations we identified throughout our analysis of the Matter specification, to help device manufacturers avoid common pitfalls, which we expect will be addressed in later revisions of the Matter specification in order to uphold its promise of sufficient device protection by the core specification.

Background

Let’s reach back a little. For the reader to be able to understand the following section, we briefly summarize the relevant core features of Matter.

Supported transports and device types

As depicted in Figure 1, Matter allows interoperability between devices of different communication technologies, which are currently Wi-Fi, Ethernet and Thread.

Here, nodes are regular devices with no special role, edge routers are devices that connect two different communication technologies, controllers are devices that can be used to control other devices in a network, and sleepy end devices are devices that can switch into idle mode to save energy.

But there’s even more. We also have bridges, which allow bridged Non-Matter devices to interact with Matter devices, as depicted in Figure 2.

Commissioning and session establishments

When we want to add a device to a Matter network, we first need to commission it. You can think of it as the initial pairing. Although Matter communication in general uses Wi-Fi, Ethernet and Thread, commissioning can be performed over Bluetooth Low Energy (BLE). The process is depicted in Figure 3.

During commissioning, three device roles can be differentiated: commissioners, commissionees and administrators. There are multiple ways in which a device can be commissioned, but the most basic one is as follows: The user enters the onboarding payload of the commissionee, which is the joining device, into the commissioner to establish its identity. This code is unique to a device and includes a setup code and cryptographic information required for the secure connection. This initiates the device discovery stage, in which the user then has to push a pairing button on the commissionee to start the beaconing by which it communicates that it needs to be added to the network and advertises its identity information. The commissioner, who listens to the announcements, discovers the commissionee and initiates the password-authenticated session establishment (PASE), which is used by the two parties to establish a secure connection using the setup code as the out-of-band (OOB) passcode.

The PASE uses a fairly young password-authenticated key-exchange (PAKE) algorithm SPAKE2+ and serves multiple means: to establish a fail-safe during commissioning, for preliminary node configuration, verification that the commissionee is a certified Matter device, installation of operational credentials and network commissioning. The operational credentials include a node operational certificate (NOC), which needs to be signed by either an Intermediate Certification Authority (ICA) or directly by the Root Certificate Authority (RCA). Having obtained a valid NOC, the commissionee becomes a new node in the Matter fabric, which you can think of as a Matter network. Note that the commissioning network is distinct from the operational network to which the device is added. An Administrator administers nodes in a fabric, while the commissioner adds nodes to a fabric. Commissioner and administrator can be the same device, but are not required to.

Nodes that own a valid NOC can initiate a certificate-authenticated session establishment (CASE) to initiate communication with other nodes in a fabric. Here, nodes mutually authenticate to each other and derive shared secrets by use of their certificates and key pairs.

The Distributed Compliance Ledger (DCL)

There is one more concept we need to outline: the Distributed Compliance Ledger (DCL), which is used to store useful device-related information. During commissioning, it is used to verify, that a device is Matter certified, but it can also store manufacturer-controlled URLs which may be integrated into a device’s application logic.

Armed with this knowledge, we are now ready to continue to the next section, in which we take a look at Matter-specific caveats.

Common pitfalls and how to avoid them

Here are the top twenty Matter-specific security pitfalls that device developers should consider, along with possible solutions. Note that the order in which the weaknesses are presented does not indicate the severity of the impact. We added recommendations on how to address these issues for some of the pitfalls. Some security problems are hard to fix due to hardware constraints, economic feasibility, technical limitations or because fixing them would raise other issues. Therefore, we did not include explicit recommendations for some of the presented security pitfalls. Instead, we recommend that manufacturers and developers take these issues into consideration in their risk analysis and try to address them in future iterations of the specification. We acknowledge that designing the security for complex interoperability framework like Matter is a very difficult task that should not be done lightheartedly.

No. 1: Implementing a weak random number generator

We found that most of Matter’s security relies on the implementation of a sufficient Random Number Generator (RNG). Even though Matter ensures at some parts of the specification (e.g., the initial PASE), that insufficient randomness by one party does not compromise the security of the protocol, insufficient randomness of both communicating parties certainly will. If you are implementing Matter devices, we cannot stress enough that you will certainly want to make use of a good RNG to not risk any attacks on the otherwise cryptographically secure protocols. The security model of Matter is designed for use with a True Random Number Generator (TRNG) with an entropy of at least 256 bits as the seeder for a Pseudo Random Number Generator (PRNG) with either CTR DRBG (with AES-CTR), HMAC DRBG (with SHA-256 or SHA-512) or Hash DRBG (with SHA-256 or SHA-512) as described in NIST 800-90A and NIST 800-90B [2, Chpts. 3.1, 3.2]. Further information on RNG attacks can be found in our blog post Attacking a Random Number Generator .

No. 2: Insufficient protection of the device passcode

Matter device passcodes are used for commissioning (the initial pairing) and can be either static, dynamic or ephemeral [2, Chpts. 5.1.7, 5.7.3.2.1]. Because dynamic passcodes are not yet fully specified, we expect that devices following the first version of the Matter specification use either static or ephemeral passcodes. The use of static passcodes, which may be distributed in text form, as a QR code or NFC tag, requires manufacturers to protect the secrecy of each individual passcode. The secrecy is risked by the following:

• Insufficient randomness of individual device passcodes
• Passcode read-out from closed packaging (NFC)
• Passcode read-out using a camera (e.g., long-range camera through a window)
• Offline brute-force attacks against the SPAKE2+ algorithm used during the PASE
• Insecure use of the recommended copy/paste function for multi-function devices, e.g., by using the shared clipboard on outdated devices, which would allow other applications access to the device passcode
• Insecure proof-of-possession during passcode recovery by the manufacturer support
• Insecure transport of recovered passcodes
• Abuse of the recovery program by manufacturer staff
• Leakage during production of packaging by staff member
• Passcode that are not sealed in closed packaging might be retrieved when packaging is opened at retail for demonstration purposes
• Read-out from device hardware (e.g., memory read-out)
• Insufficient education of users on how to securely store credentials
• Resale of used devices (static passcodes)
• Accidental disclosure via the MTop URL parameter in the manufacturer custom flow

Any failures to protect passcode secrecy allow an attacker to either eavesdrop on commissioning, which, besides others, leaks the network secret used for the underlying channel (e.g., Wi-Fi WPA-2 network key), or allows an attacker to commission the device under specific circumstances.

No. 3: Insecure implementation of the multi-admin and multi-fabrics feature

Multi-admin [2, Chpt. 12] is a feature that provides much usability, but comes at a price: multi-admin risks, that an attacker is able to obtain administrative rights without the user noticing. We noticed that the description of the multi-admin and multi-fabrics feature is currently underspecified, which leaves room for misinterpretations which in many cases significantly impact device security. To the best of our understanding, we believe that the multi-admin feature can currently only be implemented securely in the following way:

Each fabric has exactly one root certificate authority (RCA), which can appoint and revoke intermediate certificate authorities (ICAs). Both RCA and ICAs may equally administer nodes in a fabric according to the devices' access control lists (ACLs), but the ICAs are not able to revoke each other or the RCA. A deviation, in which multiple RCAs, or similar administrators of equal power exist within a fabric, risks multiple additional security problems and make it far easier for an attacker to abuse the multi-admin feature to gain control over a device. It currently seems possible for administrators to revoke privileges of other administrators. However, the specification unambiguously allows multiple administrators that are unrelated by any common roots of trust [2, Chpt. 2.4]. In this case, attacks that target the basic commissioning method (BCM) [2, Chpt. 5.6.2] or enhanced commissioning method (ECM) [2, Chpt. 5.6.3] are easier to achieve.

BCM is optional and risks, that an attacker is able to become administrator if they are in possession of the passcode, connected to the underlying communication channel, and respond faster than the user’s genuine multi-admin. An attacker that is able to trigger BCM is not able to escalate privileges unless they are in possession of the passcode.

ECM is mandatory and requires no knowledge of the passcode, but instead the ability to surveil the output of the administrator which displays or audio-outputs the ephemeral passcode. Apart from that, the attack remains the same as with BCM. ECM adds another weakness when an attacker gains one-time access to the administrative application because this would allow the attacker to trivially add their own devices without requiring passcodes. Given that administrative applications will probably be mostly used on smartphones, social engineering-based attacks where a phone is borrowed for a call (or other pretexts) are likely to succeed unless the administrative application itself is protected with a passphrase (and auto-logout), hindering the attacker from opening the administrative interface. Choosing the right mode depends on the device type and target group, which developers should take into consideration.

As a side remark, ECM with audio output and an external (potentially third-party) voice assistant enabled such as Alexa, Cortana or Siri has quite obvious security implications some technically aware users are probably not willing to risk. There already is smartphone malware that records audio , so let’s better consider that new malware might not only record audio, but also analyze Matter traffic and auto-reply in ECM, which is a horrific scenario.

No. 4: Failure to achieve unique identifiers

Matter uses various identifiers (IDs) [2, Chpt. 2.5], such as the fabric ID, node ID and group ID. These three identifiers need to be unique to avoid unspecified behavior. However, because their uniqueness is guaranteed in a module referred to as the administrative domain manager (ADM), which is explicitly out-of-scope of the specification, manufacturers need to ensure themselves that they implement unique and non-colliding identifiers. For fabric identifiers, this is even more difficult, because sometimes, compressed fabric identifiers are used instead, and we therefore suggest to include checks against collision of compressed fabric identifiers, as well. Non-unique identifiers also risk undefined behavior in user interfaces.

No. 5: Risking access control list wildcards and inconsistencies

ACLs in Matter are empty after factory reset and deny access by default. However, empty subject lists in a DCL grant access to any subject. When developing a Matter device, manufacturers should therefore ensure to not risk the production of wildcards when a subject is removed from a subject list [2, Chpt. 6.6.2.2], for example by making the removal idempotent such that a subject list is removed if an empty subject list would be created.

Administrators are sometimes required to alter an ACL entry for a group. However, because timely success of the modification cannot be guaranteed, it is possible that a node grants obsolete privileges until it receives the update. Even worse, there is a risk that when the connection fails too often, inconsistencies in group ACL entries are achieved, which an attacker could try to abuse.

No. 6: Risks specific to bridges and bridged devices

Non-Matter devices can be integrated into a Matter network with bridges [2, Chpt. 9.12]. An administrator is not meant to distinguish bridged devices from Matter-native devices, but will instead grant requested privileges to the bridge, which then inherits all of its privileges to the bridged devices. Manufacturers must take caution to grant bridges as few privileges as necessary, especially if the communication between bridge and bridged device is less secure than communication in Matter. Furthermore, we advise that administrative interfaces group bridged devices and their bridges together in such a way that it intuitively becomes clear that the devices share the same set of permissions. We suggest to educate users about the security implications of using bridges, to avoid any misunderstandings where a user wishes to grant permissions exclusively to one of the bridged devices, but not to the bridge itself or any of the other bridged devices. Keep in mind that end users are mostly technically unaware and usually fail to understand concepts that are self-evident for developers.

No. 7: Risking privacy by advertising vendor and product identifiers via DNS or Bluetooth

Advertising the vendor ID (VID) and product ID (PID) can leak potentially private information [2, Chpt. 5.4.2.5.6] and might even allow to infer information about the interiors of a building (e.g., the number of body scales might be equal to the number of bathrooms). We recommend to disable the advertisement of VIDs and PIDs per default, but allow the user to opt-in for the advertisement for usability reasons.

No. 8: Risks specific to controllers, commissioners, edge routers, bridges, OTA providers and OTA requestors

Controllers, commissioners, edge routers, bridges, over-the-air (OTA) providers and OTA requestors play powerful roles in a Matter network. While edge routers and bridges have an inherent middle-man position that makes it easier for them to drop and modify traffic, controllers (also referred to as administrators), commissioners and bridges influence which devices can participate in Matter communication and how, while OTA providers and OTA requestors have an impact on the device firmware of other devices. Because of this, these devices are of special interest for an attacker, and therefore, each device of this type should be especially security-hardened.

No. 9: Unsanitized user input

Some devices might allow their users to modify the device name (DN), also referred to as friendly name [2, Chpt. 4.3.3]. This name can be advertised over DNS and is probably a popular attribute to display in user interfaces to allow the user to select a device. If not validated and sanitized properly, any user input such as the DN might be abused for code injection.

No. 10: Rogue commissioners

During commissioner discovery, a node can discover and display potential commissioners [2, Chpt. 4.3.3]. But because any of the advertised information can be spoofed, an attacker can trick a commissionee into commissioning with an evil twin commissioner, which we call the rogue commissioner. Such attacks are expected when the user interface displays the advertised information in such a way, that the user is tricked into assuming that the malicious device is the genuine commissioner, for example by cloning VID, PID, DN and/or MAC address, depending on which of the information is displayed to the user. The attack is even more devastating if the attacker is able to suppress advertisement by the genuine commissioner, for example by dropping the advertisement as an edge router on the route between genuine commissioner and commissionee. The attack requires the attacker to be in possession of the passcode, and risks commissioning to an attacker-controlled device in an attacker-controlled network. The following figures depict two different ways in which a rogue commissioner may be perceived by a user:

No. 11: Devices may ignore device attestation verification results

Even though Matter advertises that only Matter-certified devices can participate in a Matter network, as of the first iteration of the specification this is not correct, because device attestation verification results may be ignored by the commissioner [2, Chpt. 5.5]. Therefore, even though the device attestation verification itself is mandatory, it is totally within the specification to perform the verification, but continue with commissioning regardless of the results. Because of this, there currently are no guarantees that commissioned devices behave according to the specification. Because being able to integrate non-certified devices is a desired feature especially for the free and open-source software (FOSS) community, we do not expect that the specification will change in this aspect, but we recommend that developers make device attestation verification an opt-out for a secure-by-design setting, while keeping in mind that unexpected behavior can occur from both commissioned and uncommissioned devices.

No. 12: Evil twin attack

When a Matter network uses Wi-Fi as the underlying communication channel, the commissioning and network configuration process becomes vulnerable against the evil twin attack, because it is near impossible for Matter to protect against this kind of attack. An evil twin attack on Wi-Fi occurs, when the attacker clones the SSID of a genuine Wi-Fi network so that auto-connecting devices connect to the malicious network instead of the genuine one. The attack might even go unnoticed if the attacker is connected to both networks and can relay the communication, taking a machine-in-the-middle (MitM) position. We suggest that the attack might be detectable by comparing traceroute results [4].

No. 13: Manipulation of the Commissioning Custom Flow Url

There is a risk that the attacker is able to trick a user into opening a malicious website with a commissioner or commissionee (which is most likely a device such as a smartphone or television), even if the attacker is not able to influence the rest of the commissioning to the genuine device. This is because the CommissioningCustomFlowUrl is determined using the PID and VID advertised by the commissionee over the unsecured device discovery [2, Chpt. 5.1.1.3]. The attacker might be able to spoof the value such that the advertisement contains a different PID or VID. This becomes problematic when there is at least one abandoned or compromised CommissioningCustomFlowUrl included in the DCL, and when the commissioning application does not check whether the DCL entry was revoked. The commissioner is not able to confirm that PID and VID are correct unless the information is explicitly provided or checked by the user, or if the application itself contains other means of restricting valid identifiers. We hope that DCL entries containing malicious URLs will be revoked upon discovery, but since there will always be someone that will be first to discover the compromise, clients accessing this information must make sure to check that the information is still valid at the moment and may ask the user to confirm the VID and PID, which can be mapped to the vendor and product name instead.

No. 14: HTTP downgrade attack

Although the specification requires links to start with HTTPS [2, Chpt. 4.2.8], implying the use of transport encryption, there is no way that the CSA or Matter specification can enforce the use of transport encryption. We therefore recommend to implement an HTTPS-only mode in devices such that unencrypted communication over HTTP is rejected to prevent HTTP downgrade attacks.

No. 15: Missing minimal requirements for underlying communication channels

Currently there are no minimal requirements for the underlying communication channel, as long as it uses Wi-Fi, Ethernet or Thread. We suggest that Matter Wi-Fi devices use WPA-2 or newer to protect the communication channel, and for commissioning over BLE version 5.2 or newer in Secure Connection Only Mode (Secure Mode 1 with Security Level 4, FIPS mode). This way, many vulnerabilities of the underlying communication channel can be mitigated, which alone are not sufficient to break the security of Matter but widen the attack surface. Another option would be to allow less secure protocols only as an opt-in, which provides compatibility with older devices.

No. 16: Manipulation of sleepy end device parameters

Sleepy end devices (SEDs) in general are equally secured as regular nodes. SED parameters are used to configure the active and idle intervals [2, Chpt. 2.9]. The attacker can deplete the node’s energy by increasing the active interval and decreasing the idle interval, and they can slow down polling by increasing the idle interval. Slowing down polling is specifically interesting if the device retrieves sensor data and is configured to issue warnings on specific values or changes, while energy depletion can cause premature end-of-life if the battery is not rechargeable or exchangeable, and can result in temporary denial-of-service (DoS). A Non-Matter-specific depletion attack can be performed by continuously messaging the SED to prevent it from switching to idle mode. During the PASE, the SED parameters are part of the context, preventing the attacker from modifying the values.

However, during the CASE and discovery, the SED parameters are transmitted such that any modification of an attacker (e.g., by a malicious edge router) goes unnoticed, because they are sent in unsecured plaintext instead of being signed, hashed or encrypted, allowing the attacker to influence polling and transmission behavior. We believe the problem is fixed in future revisions by moving SED parameters to the to-be-signed part of the exchange, but in the meantime, manufacturers should be aware that the receiver of a session establishment message might assume other parameters than those sent by the genuine sender.

No. 17: Status report message injection

There are four unsecured status report messages of the secure channel protocol that can be injected into the network [2, Chpt. 4.10.1.3]: NO_SHARED_TRUST-ROOTS, BUSY and INVALID_PARAMETER can be used to interrupt PASE and CASE session establishments between two genuine devices, and SESSION_ESTABLISHMENT_SUCCESS, which is used to indicate successful session establishment, but can cause undefined behavior when a device implements a flawed process flow. Using BUSY, the attacker is able to discard unfavorable randoms as depicted in the below figure, because the session establishment is restarted after the duration of the requested timeout, and a fresh random is sent. While, as long as a sufficiently strong RNG is implemented, the entropy of the random is sufficient for the establishment to remain secure, an attacker (or pentester) could use this status report message to remotely examine the randomness of another device’s RNG.

No. 18: Revocation from groups

There is a significant risk that revocation from a group is handled in a way that the revoked member is able to participate in group communication far longer than is expected by the user. This is because operational group keys are derived from epoch keys [2, Chpt. 4.15]. Nodes can be given up to three epoch keys simultaneously. Epoch-based group communication allows scaleable revocation of group members by not handing out the next epoch key, which ultimately denies access to group communication from a cryptographic perspective.

However, in Matter, epochs are recommended to last for days to weeks. In worst case, an administrative interface implements group revocation such that the administrator responds with immediate removal of the revoked node’s representation within the group member list, while maybe instructing the revoked node to remove its keys. In this situation, the user would be misled to assume that the revoked group member is not able to participate in group communication the moment it is shown as removed, while the node in worst case is still able to participate, especially in terms of listening, in group communication for up to two epochs, which is significantly longer than a technically unaware user would expect. This risks serious privacy and security breaches, for example if an employee is granted temporary access to a system, potentially under supervision, that is revoked shortly after. Here, the employee gains unsupervised access to a group, which might become an easily overlooked security risk.

The problem can be prevented by ensuring that the Admin Refresh command is used after group member revocation, so that the epoch keys are completely rotated. However, this somehow reduces the benefits of using epochs for group communication, so we recommend to make this behavior an opt-in, allowing users to switch between the two modes. More importantly, administrative interfaces should ensure to correctly display the exact point of time at which a group member is fully removed from a group from a cryptographic perspective.

No. 19: Underspecification of timed interactions

Matter uses timed interactions to protect against replay attacks [2, Chpt. 7.6.10]. We consider them to be a great protective measure, and because it has not yet been specified, recommend to implement them in a way that limits triggering of an action to at most once during the specified interval. This is because implementations are not required to support cache-and-sync message counter synchronization, which can occur on certain events such as device reboot, making the device potentially vulnerable against replay attacks because the first authenticated message is trusted in the trust-first policy. To make it clear, both message counters and timed interactions protect against replay attacks, each narrowing the time frame in which such attack is possible to an extent where the attack is unlikely to succeed. By closing the receive window after the interaction was received, the replay attacks (of secured communication) become almost impossible.

No. 20: Dysfunctional implementations of event logging

Logging in Matter is implemented via event records [2, Chpt. 7.14]. Events are categorized into three priority levels (debug, info, critical). Newer event records may overwrite older event records of the same priority level. However, it is not described how buffer is reserved for each priority level. This is probably a no-brainer, but make sure that for each priority level, sufficient space in buffer is reserved instead of relying on an even distribution when the buffer is filled for the first time.

Conclusion

We found that Matter keeps up with most of its security claims. We pointed out some of the weaknesses that manufacturers might want to address to further strengthen the security of their products. The presented weaknesses were taken from a master’s thesis by Melissa Loos, which was created at SCHUTZWERK GmbH in cooperation with Ulm University . It is publicly released at the Oparu platform of Ulm University . Feel free to contact us if you want our help in further improving the security of your Matter products.

References / Credits

• [1] Melissa Loos. Security Analysis of Matter , Masterthesis, Ulm University, January 2023.
• [2] Connectivity Standards Alliance. Matter Core Specification 1.0 , October 2022.
• [3] Connectivity Standards Alliance. Matter Security and Privacy Fundamentals , March 2022.
• [4] Alex Burns, Longfei Wu, Xiaojiang Du, Liehuang Zhu. A Novel Traceroute-Based Detection Scheme for Wi-Fi Evil Twin Attacks , December 2017.
• Download Matter security pitfalls as PDF .

Credits: The elaborations associated with this subject are part of the results of a Master’s thesis by Melissa Loos created at SCHUTZWERK GmbH in cooperation with Ulm University .

~ Melissa Loos