Chapter 13. Security Requirements
13.1. Overview
Each Matter security and privacy requirement references the underlying countermeasure (CM) and threat (T) in the Threat Model that motivated the need for the requirement. The requirements are grouped by topic. Unless stated otherwise, these requirements typically address all Devices and Nodes (i.e. all implementations of Matter functionality). Some requirements are called out specifi cally for a particular group of implementations, or Roles.
13.2. Device vs. Node
For some requirements, we need to differentiate between a Node (the entity which supports the Matter protocol stack) and a Device (a piece of equipment containing one or more Nodes).
- If the Node contains all of the Matter functionality, nevertheless it will probably rely on some security features of the
- If the Node uses Matter functionality provided by the Device, the requirements obviously hold for both the Node and the
13.3. Commissioning
- Nodes SHALL stop both commissioning and unsecured rendezvous actions after a specified time period from the beginning of the commissioning mode when commissioning has not been con cluded, unless allowed for other purposes such as Commissionable Node Discovery. The time period for commissioning and unsecured rendezvous announcements SHALL follow require ments as specified in Section 5.5, “Commissioning Flows” and Section 5.4.2.3, “Announcement Duration” [CM8 for T5, T7]
- Nodes SHALL utilize multiple hash iterations in PBKDF, as required by definitions in Section 3.9, “Password-Based Key Derivation Function (PBKDF)”. Nodes SHALL validate the bounds of the iteration count for PBKDF, to respect the minimum and maximum values stated in the cryptog raphy primitives section (see Section 3.9, “Password-Based Key Derivation Function (PBKDF)”). [CM99 in T102]
- Nodes SHALL exit commissioning mode after 20 failed commission attempts (see Section 5.5, “Commissioning Flows”). [CM100 for T101, T112]
- Devices SHALL include a Device Attestation Certificate and private key, unique to that Device. [CM23 for T22, T24, T34, T86]
- When the setup code is not permanently attached to a device, for example, it is removable or only found in the device setup guide, the device SHALL NOT deliver the Onboarding Payload using an NFC tag [CM4 for T90].
- If an NFC Tag is used to convey the Onboarding Payload from a device to a Commissioner, depending on how the NFC tag is associated with the device (e.g. device package, attached to the device, connected to the device…), the NFC Tag SHALL only allow the alteration of the Onboard ing Payload and the reading thereof in ways and in device states attackers cannot exploit to illic
itly onboard the device (e.g., the alteration of the NFC Tag Onboarding Payload SHALL only be possible while being manufactured, the NFC tag read-out SHALL NOT be possible when the device is still in the packaging, the NFC Tag read-out SHALL only be allowed during the enabled commissioning window). [CM4 for T90]
- After initial Commissioning of a Device, subsequent Commissioning SHALL only be triggered by an Administrator or an equivalent entity where the user gives administrative consent. [CM2 for T1]
13.4. Factory Reset
- Devices and Nodes SHALL have a factory reset [CM15 for T16, T17, T79, T82]
- Factory reset SHALL remove from the Node all security- and privacy-related data and key mate rial created during or after commissioning except data explicitly required to persist across resets. [CM35 for T16, T17, T79, T82]
See the following sections for detailed factory reset requirements.
- Section 6.4.3, “Node Operational Identifier Composition”
- Section 6.4.10, “Security Considerations”
- Section 6.6.3, “Access Control List Examples”
- Section 7.12.1, “Persistence”
- Section 7.14, “Event”
- Section 11.11, “General Diagnostics Cluster”
- Section 11.19.4.2, “Image Verification”
- Section 11.17.5.1, “NOCs Attribute”
- Section 11.17.5.2, “Fabrics Attribute”
- Section 11.17.5.4, “CommissionedFabrics Attribute”
- Section 11.17.5.5, “TrustedRootCertificates Attribute”
13.5. Firmware
- Nodes SHALL support OTA firmware updates, either using Matter-provided means (see Section 11.19, “Over-the-Air (OTA) Software Update”) or proprietary means. [CM58 for T59]
- Nodes SHALL validate the authenticity and integrity of the firmware prior to installation, such as through cryptographic means (see Section 19.4.2, “Image Verification”). [CM58 for T59]
- Nodes SHOULD validate configuration and input for length, and acceptable values and ranges before applying them. This validation is dependent on the configuration or input being applied (see Access Control Cluster). Configuration and input validation is explicitly defined in relevant sections of the specification. [CM46 for T55]
13.6. Security Best Practices
This section describes best practices that Matter implementors SHOULD implement. Matter imple menters SHALL indicate whether they comply or not to the best practices. Matter certification will not itself test that these requirements have been met.
13.6.1. Cryptography
- Devices and Nodes SHOULD include protection (if it exists) against known remote attacks that can be used to extract or infer cryptographic key material. [CM107 for T94]
- Devices SHOULD protect the confidentiality of attestation (DAC) private keys. The level and nature of protection for these keys may vary depending on the nature of the Device. [CM77 for T22]
- Nodes SHOULD protect the confidentiality of Node Operational Private Keys. The level and nature of protection for these keys may vary depending on the nature of the Nodes. [CM87 for T87, T110, T120]
- Cryptographic keys SHALL be randomly chosen using a cryptographically secure random num ber generator in accordance with algorithms defined in Section 3.1, “Deterministic Random Bit Generator (DRBG)”. [CM39 for T39]
- Devices SHALL use non-repeating initialization vectors for a given session [CM78 for T81]
13.6.2. Commissioning
- Manufacturers SHOULD control the number of DACs issued under their Vendor [CM24 for T23, T34]
- Where practical, the setup code SHOULD NOT be photograph-able or visible when installed (e.g., QR code hidden with a flap). [CM89 for T90]
- Uncommissioned Devices SHOULD only be available to be commissioned with some form of physical proximity user interaction (e.g. power cycle or button press). [CM3 for T15, T90, T92]
- For Devices subject to physical tampering (e.g. doorbell, camera, door lock, devices designed for outdoor use cases), the physical interaction to initiate commissioning and/or the setup code (QR code, NFC Tag or Manual code) SHOULD NOT be accessible to a physical attacker. E.g. setup code is removable or not on the device, the button used to initiate commissioning for the lock is inside the house. [CM4 for T3, T84]
- A Commissioner or Administrator SHOULD only add Root Certificates that it trusts to a Node. [CM36 for T153]
- A device manufacturer SHOULD implement Basic Commissioning Method only for devices that adequately secure the Passcode. [CM154 for T173]
13.6.3. Firmware
- Vendors of Matter implementations (including their suppliers of Matter functionality) SHOULD have a public vulnerability reporting mechanism and policy and actively monitor, identify and rectify in a timely manner security vulnerabilities throughout the publicly stated security life-
cycle policy of the product. Typical responsible disclosure guidelines allow vendors from 60 to 120 days to patch a vulnerability, but the implementation of such a program is at each vendor’s discretion. [CM59 for T9]
- Devices SHOULD have a verified boot based in an immutable root of trust to verify the authen ticity of firmware. Commissioners SHOULD only be loaded on a computing platform that has such a verified boot. If devices cannot support verified boot, devices SHOULD perform verifica tion on any firmware update before applying the new firmware. [CM22 for T16, T20]
13.6.4. Manufacturing
- Fusing of Devices in production SHOULD be done to limit unintended access to hardware com ponents. For example, vendors may disable debug interfaces, and program trust anchors for secure boot. There are multiple options to secure fusing on the factory floor (e.g., physically securing the fusing station, pre-fusing the silicon, etc). [CM113 for T117]
13.6.5. Resiliency
- Matter implementations SHOULD implement resiliency features (e.g., responding to secure boot failures with recovery or error signaling mode) to detect and handle compromise. [CM57 for T59]
13.6.6. Battery Powered Devices
- Battery powered Devices SHOULD respond to excessive queries by rate limiting (even limiting the rate to zero if desired). [CM51 for T52, T53]
13.6.7. Tamper Resistance
- Protection against physical attacks (especially those that impact cybersecurity) MAY be needed for some Devices, as determined by the manufacturer. [CM62 for T60]
13.6.8. Bridging
- Admins SHOULD only grant privileges to a Bridge or Bridged Device (sending commands from that Bridged Device towards a Matter node) that the User is comfortable implicitly granting to all other Bridged Devices exposed by that Bridge. Background: Matter’s ACL mechanism does not provide a way to grant privileges to only a single endpoint (Bridged Device) from a node (the Bridge).
13.6.9. Distributed Compliance Ledger
- Vendors SHOULD avail themselves of the DCL store-and-forward functionality so that they can control posting of data about their products to the DCL. [CM160 for T170]
- Access to Validator Nodes SHOULD be restricted (e.g., with VPN that only permits Validator Nodes, Observer Nodes, and authenticated clients with write access). [CM163 for T169, T177, T180, T183, T186]
- Vendors SHOULD run and use their own Observer Nodes and restrict access to it to make sure
that it stays available to the vendors’ DCL clients. [CM166 for T180, T182]
- Vendors SHOULD protect DCL private keys in Hardware Security Module (HSM) equipped servers. [CM167 for T168, T186]
- All parameters passed in transactions and queries to the DCL SHALL pass input validation checks done by the implementation of the DCL. [CM169 for T185]
13.7. Threats and Countermeasures
This section lists identified threats to Matter and countermeasures to mitigate those threats. This section is meant to be informational and not as normative requirements.
Table 93, “Threats” describes the threats, the agent involved in the threat as well as evaluates the consequences. This includes the severity, impact and likelihood of the threat being exploited.
Table 93. Threats
Threat Description | Threat Evaluation | Counter measure | |||
ID | Description | Threat Agent | Impact/Consequence | Severity | ID |
T1 | Commission an already Commis sioned Node for control that may be difficult to detect (e.g., IP Camera to stream video) | Malicious house guest (brief physi cal access). | Silent control of Node and access to sensitive Node data (e.g. IP Cam era traffic). If only 1 commissioning is allowed, user would detect issue later if/when they try to use Node. | High | CM2 |
T3 | Reset Device and Commission for silent control (e.g. IP Camera to stream video). | Malicious house guest (brief physi cal access). | Silent control of Node and access to sensitive Node data (e.g. IP Cam era traffic). If only 1 commissioning is allowed, user would detect issue later if/when they try to use Node. | High | CM4 |
T5 | IoT device adver tises information that can be used to identify vulnera bilities. | Malicious device or person with local network access. | Use information about the Device to exploit a (known) vulnerability. | High | CM6, CM7, CM8 |
Threat Description | Threat Evaluation | Counter measure | |||
T7 | IoT device adver tises information that can be used to identify, profile, or target a home or a user. | Malicious device or person with local network access. | Use information about available accessories to target a given home or user (e.g. to rob). | Medium | CM6, CM7, CM8 |
T9 | Exploit vulnerabil ity in the Device to gain arbitrary con trol over Device. | Any. | Unexpected control of Device to gain access to home data, instill fear, etc. | High | CM58, CM59 |
T15 | Commission an uncommissioned Node without physical access to Device | Malicious neigh bor or other nearby active attacker | Silent control of Node and access to sensitive Node data (e.g. IP Cam era traffic). | High | CM3 |
T16 | Seller of an Device (most likely a used one) intentionally leaves malicious software or config uration on the Device to compro mise future traffic. | Malicious Device seller. | Control or access sensi tive data of Device. | Medium | CM15, CM16, CM17, CM21, CM22, CM35 |
T17 | Device buyer or trash picker dumps memory to find previous owner’s Device keys, group keys, and network cre dentials. | Malicious Device buyer or trash picker. | Access to sensitive data and ability to inject trusted data or even commands. | Medium | CM15, CM16, CM17, CM35 |
T20 | Firmware (any software on Device that can be modified) is modi fied by attacker in factory (or remotely through factory) | Worker at factory or programming location or remote attacker |
1. Local network behavior issues 2. Infected Nodes lead ing to data breach, mal function, denial of ser vice, or attacks by this Node on other Nodes |
Medium | CM21, CM22 |
Threat Description | Threat Evaluation | Counter measure | |||
T22 | Cloned Device pro duced (with identi cal credentials to a proper Device). | Anyone with phys ical access to a Device from which they can extract Device Attestation credentials. |
1. Brand damage if Device is of lower qual ity. 2. Loss of revenue. 3. Lack of function or interoperability if Device does not func tion properly. 4. Lack of security if Device does not have proper security mea sures. 5. Lack of support from manufacturer for cloned Devices. |
Medium | CM23, CM77 |
T23 | Counterfeit Device produced (with unique but appar ently authorized credentials) | Worker at factory or programming location |
1. Brand damage if Device is of lower qual ity. 2. Loss of revenue. 3. Lack of function or interoperability if Device does not func tion properly. 4. Lack of security if Device does not have proper security mea sures. 5. Lack of support from manufacturer for cloned Devices. |
Medium | CM24 |
T24 | Factory provi sioned keys cap tured in factory, transit, or store (e.g., with fault injection or other tampering). |
1. Worker in sup ply chain. 2. Attacker who goes to retail store |
Control of Device and access to sensitive Device data (e.g. IP Camera traffic). | Medium | CM23, CM113 |
T34 | Cloned Device enters the net work. | Manufacturer sell ing cloned Devices. | Loss of revenue or brand issues for origi nal manufacturer. | Low | CM23, CM24 |
Threat Description | Threat Evaluation | Counter measure | |||
T39 | Guessing security keys via brute force attack. | Attacker within radio range, cap tures encrypted network packets. |
Control or access sensi tive data of Device. Even control entire net work if the private key for the Operational Cer tificate of a Controller can be guessed. |
High | CM39 |
T52 | Malicious Device off the network causes battery powered Device to wake too often. | Attacker using a Device on the net work. | Shortened battery life of nearby Devices. | Medium | CM44, CM51 |
T53 | Malicious Device off the network interrupts battery powered messages too often and greatly reduces battery life. | Attacker using a Device on the net work. | Shortened battery life of nearby Devices. | Medium | CM44, CM51 |
T55 | Device reconfig ured improperly. | Attacker using a Device on the net work. | Device could be config ured such that it does not properly behave. | Medium | CM45, CM46, CM47 |
T59 | Maliciously crafted message exploits Device vulnerability, causing Device compromise. | Attacker using a Device on the net work. | Trusted Device could be hijacked. | High | CM57, CM58 |
T60 | Physical tamper ing with Device permits compro mise. | Attacker with physical access to Device. | Trusted Device could be hijacked. | Medium | CM62 |
T79 | Device marked for destruction reused in network. | Installer or return agent. | Damaged or obsolete Devices may re-enter the network. | Low | CM15, CM16, CM20, CM35 |
Threat Description | Threat Evaluation | Counter measure | |||
T81 | Attacker uses pre dictable Initializa tion Vectors to derive crypto keys. | Attacker able to observe network traffic from the Device. | Attacker discovery of Device crypto keys and other secrets, which can lead to control of other Devices if the Device has such privi leges. | High | CM78 |
T82 | Device buyer dumps memory to find previous owner’s user data. | Malicious Device buyer or dumpster diver. | User data may be leaked. | Medium | CM15, CM35 |
T84 |
Person with physi cal access to already installed Device resets. Device then scans QR code to gain access. |
Attacker with physical access to Device. | Control of Device and access to sensitive Device data (e.g. IP Camera traffic). | Medium | CM4 |
T86 | Leak certificate or Device identity private key to appear as valid Device. | Physical or locally compromised attacker. | Device appears as valid Device. | Low | CM23 |
T87 | Malicious Device or party poses as valid Matter Node using operational credentials | Attacker on the local network or remotely control ling a Node on the local network | Group keys and sensi tive data revealed to an invalid Node | Medium | CM87 |
T90 | Long range cam era captures QR code at Commis sioning time or otherwise. | Malicious neigh bor, robber, or other nearby active attacker. | Attacker manages to connect Device to their gateway or account. | Medium | CM3, CM89 |
T92 | Microphone in the house can capture person speaking the setup code and use that to MITM Commissioning. | Malicious neigh bor, robber, or other nearby active attacker | Attacker manages to connect the Node to their gateway or account | Medium | CM3 |
Threat Description | Threat Evaluation | Counter measure | |||
T94 | Remote attack used to extract keys and other secrets. | Attacker able to access the Device remotely or over local network. | Attacker discovery of Device crypto keys and other secrets, which can lead to control of other Devices if the Device has such privi leges. | High | CM107 |
T101 | Malicious Device or person with local network access attempts to guess setup code via online brute force attack. | Attacker on the local network. | Control of Device and access to sensitive Device data (e.g. IP Camera traffic). | High | CM5, CM100 |
T102 | Malicious Device or person with knowledge of passcode verifier uses offline brute force attack to derive setup code. | Attacker with remote access. | Control of Device and access to sensitive Device data (e.g. IP Camera traffic). | High | CM5, CM99 |
T110 | Malicious device or party poses as valid Matter Administrative Node using opera tional credentials | Attacker on the local network or remotely control ling a Node on the local network | Control of Node and access to sensitive Node data (e.g., IP camera traffic) | High | CM87 |
T112 | Malicious Device(s) or per son(s) with local network access attempts to guess setup code of many Devices via online brute force attack. | Attackers on the local network. | Control of Device and access to sensitive Device data (e.g. IP Camera traffic). | Medium | CM5, CM100 |
T117 | Incorrect fusing of production Devices. | Contract manufac turer, factory worker. | Device assets are vul nerable, security poli cies including secure boot might not be enforceable, etc. | High | CM113 |
Threat Description | Threat Evaluation | Counter measure | |||
T120 | Data from Matter Nodes is shared with non-Matter or unauthorized entities (e.g. data leakage to adja cent non-Matter Nodes) |
Any adversarial process running in the node that has enough privileges to modify ACLs. Secure boot is not sufficient protec tion if the device boots rarely and the malicious process was spawned post-boot up. |
Matter data may be used in inappropriate or unauthorized ways potentially harming the owner. | High | CM87 |
T153 | Commis sioner/Administra tor adds untrust worthy Root CA to Node. | Malicious, com promised, or poorly advised Commis sioner/Administra tor. | Attacker can create NOCs that enable impersonation and MITM of Secure Chan nels. | High | CM36 |
T168 | DCL Private Key Exfiltration. | Attacker obtains one or more pri vate keys of a com pany with DCL writer privilege. |
Attacker can add to the block chain on behalf of the company. Can change the OtaUrl to point to old and known-vulnerable firmware or prevent an update from being installed. |
High | CM163 |
T169 | DoS/DDoS of Val idators Nodes. |
Attack can direct a DoS attack or resource exhaus tion attack against validators. Attacker only needs to DoS 1/3+1 of validators to DoS consensus. |
New blocks cannot be added. | High | CM163 |
T170 | Unintended or premature expo sure of informa tion. | Company or certi fication lab posts device details to the chain and it is validated. | Immutability of block chain means the infor mation is permanently on the chain. | High | CM160 |
Threat Description | Threat Evaluation | Counter measure | |||
T173 | Malicious Device or person with local network access and knowl edge of the pass code attempts to pair with a com missioned device when someone else opens the commissioning window using Sec tion 5.6.2, “Basic Commissioning Method (BCM)” and the device’s Passcode. | Attacker on the local network | Control of Device and access to sensitive Device data (e.g. IP Camera traffic) | Medium | CM41, CM152, CM154 |
T174 | Malicious Device gains knowledge of the Passcode on an uncommis sioned Device, commissions the Device, and then puts it back into commissioning mode with the same Passcode using Section 5.6.2, “Basic Commis sioning Method (BCM)” or Section 5.6.3, “Enhanced Commissioning Method (ECM)” to avoid detection. | Attacker on the local network | Control of Device and access to sensitive Device data (e.g. IP Camera traffic) | Medium | CM41, CM152 |
Threat Description | Threat Evaluation | Counter measure | |||
T175 | Malicious Device with knowledge of the Passcode com missions an uncommissioned Device and then puts it back into commissioning mode with the same Passcode using Section 5.6.2, “Basic Commis sioning Method (BCM)” or Section 5.6.3, “Enhanced Commissioning Method (ECM)” to avoid detection. | Attacker on the local network | Control of Device and access to sensitive Device data (e.g. IP Camera traffic) | Medium | CM41, CM152 |
T177 | Attacker exploits a vulnerability that is common to most or all of the Valida tor Node software. | Attacker with some sort of DCL access (maybe just read, which is open to all). | Many Validator Nodes misbehave (e.g., approving adding or revoking a PAA or changing an OtaURL). | High | CM163 |
T180 | Attacker accesses Observer Node or Validator Node with unauthenti cated READ CLI protocol, mounts a DoS or DDoS attack. | Attacker that can send network messages to a DCL Observer Node or Validator Node. | DCL capacity dimin ished or eliminated. Unable to communicate important things like revocation of PAA. | High | CM163, CM166 |
T182 | DoS/DDoS of Observers Nodes. | Attack can direct a DoS attack or resource exhaus tion attack against Observer Nodes. If enough Observer Nodes are impacted by a DoS attack, the DCL may become unavailable. | DCL unavailable | High | CM166 |
Threat Description | Threat Evaluation | Counter measure | |||
T183 | DoS on Trustees’ approval process. |
Submit many PRO POSE_ADD_AC COUNT requests. The Trustees can be overwhelmed with illegitimate requests. Requires compromise of a Trustee, although replay is possible. |
Trustees overloaded | Medium | CM163 |
T185 | DCL Denial of Ser vice. Attacker writes a value to the ledger that is very large or out of bounds. | Authorized attacker sends a write request with very large para meter payload. | Very large ledger blocks added to ledger. This could cause valida tion problems. DOS on Observer Nodes if response is very large. | High | CM169 |
T186 | Test House posts incorrect informa tion about a ven dor’s product. | Authorized test house. | False product info in ledger | High | CM163, CM167 |
Table 94, “Countermeasures” describes the various countermeasures to the threats listed in Table 93, “Threats”.
Table 94. Countermeasures
ID | Description |
CM2 | After initial Commissioning of a Device, subsequent Commissioning can only be triggered by an Administrator or an equivalent entity where the user gives administrative consent. |
CM3 | Commissioning is started with some form of physical user interaction (e.g. power cycle or button press). |
CM4 | For Devices subject to physical tampering (e.g. doorbell, camera, door lock, devices designed for outdoor use cases), the physical interaction to initiate com missioning and/or the setup code is not accessible to a physical attacker. E.g. setup Passcode is removable or not on the device, the button for the lock is inside the house. |
CM5 | All Devices include a randomly generated setup passcode and a corresponding passcode verifier derived from the setup passcode via a PBKDF. The setup code includes at least 27 bits of entropy compliant with a recognized standard (e.g., NIST SP 800-90B). |
ID | Description |
CM6 | Unsecured rendezvous are enabled by a user action and, upon time-out or com missioning failure, will cause deletion of any state information. Examples of “user actions” are pressing a physical button, power-cycling a Device, and leveraging a previously commissioned account. |
CM7 | Minimize OS and other version information advertised during discovery. |
CM8 | Both commissioning and unsecured rendezvous actions time-out after at most 15 minutes from the beginning of the commissioning mode when commissioning has not been concluded. |
CM15 | Devices have a physical button or trigger for factory reset. |
CM16 | Devices rotate keys at specified triggers (e.g. Factory Device Reset). |
CM17 | Devices implement Perfect Forward secrecy key agreement protocols that give assurances that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised. |
CM20 | Revoke Device credentials and privileges when the Device is removed from the home. |
CM21 | Devices have cryptographically signed firmware, including all firmware and soft ware on the Device. |
CM22 | Devices have a verified boot based in an immutable root of trust to verify the authenticity of firmware. |
CM23 | All Devices include a Device Attestation Certificate and private key, unique to that Device. |
CM24 | Manufacturers control the number of DACs issued under their Vendor ID. |
CM35 | Factory reset removes all local data and key material created during or after com missioning except data explicitly required to persist across resets. |
CM36 | A Commissioner / Administrator only adds Root Certificates that it trusts to a node. |
CM39 | Cryptographic keys are randomly chosen using the strong entropy separately required and the cryptographic algorithms and key lengths specified by Matter. |
CM41 | Administrators can view the set of Fabrics on each Device (i.e., Attributes for the Node Operational Credentials Cluster). |
CM44 | Administrator responds to reported or detected attacks and malfunctions (e.g., by adding Devices to a denylist, notifying the user, changing group keys, or hopping channels). |
CM45 | Configuration for secure channel protocol is carefully negotiated and validated by both parties. |
CM46 | Devices validate configuration and input changes for length, character type, and acceptable values and ranges before applying them. This validation is dependent on the configuration or input being applied (e.g. ACL entries). Configuration and input validation is explicitly defined in relevant sections of the specification. |
ID | Description |
CM47 | Device management service uses a secure communication mechanism for recon figuration. |
CM51 | Battery powered Devices respond to excessive queries by rate limiting (even limit ing the rate to zero if desired). |
CM57 | Devices implement resiliency features (e.g., responding to secure boot failures with recovery or error signaling mode) to detect and handle compromise. |
CM58 | Devices support OTA firmware updates. Devices validate the authenticity and integrity of the firmware prior to installation. |
CM59 | Manufacturers monitor newly discovered vulnerabilities and provide software updates to address them. |
CM62 | Protection against physical attacks (especially those that impact cybersecurity) is needed for some Devices, as determined by the manufacturer. |
CM77 | All Devices protect the confidentiality of attestation (DAC) private keys. The level and nature of protection for these keys may vary depending on the nature of the Device. |
CM78 | Devices use random initialization vectors. |
CM87 | All Nodes protect the confidentiality of operational credential private keys. The level and nature of protection for these keys may vary depending on the nature of the Nodes. |
CM89 | The setup code is not photographable (e.g., NFC) or not visible when installed (e.g., QR code hidden with a flap). |
CM99 | Devices utilize multiple hashes in PBKDF. |
CM100 | Device exits commissioning mode after 20 failed commissioning attempts. |
CM107 | Devices include protection (if it exists) against known remote attacks that can be used to extract or infer cryptographic key material. |
CM113 | Fusing of Production Devices is done correctly. For example, disabling debug interfaces, and programming trust anchors for secure boot. There are multiple options to secure fusing on the factory floor (e.g., physically securing the fusing station, pre-fusing the silicon, etc). |
CM152 | Device manufacturers provide a way to secure a static Passcode after initial com missioning so that it is not available for unauthorized agents. |
CM154 | A device manufacturer implements Section 5.6.2, “Basic Commissioning Method (BCM)” only for devices that adequately secure the Passcode. |
CM160 | Vendors sign off on some other entity posting data about their products to the DCL. |
CM163 | Tightly restrict access to Validator Nodes (e.g., with VPN that only permits Valida tor Nodes, Observer Nodes, and authenticated clients with write access). |
CM166 | Matter vendors run and use their own Observer Node and restrict access to it to make sure that it stays available to that company’s DCL clients. |
ID | Description |
CM167 | Matter vendors protect DCL private keys in HSM equipped servers. |
CM169 | All parameters passed in transactions and queries to the DCL pass input valida tion checks. |