페이지 선택
Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors
Search in pages

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

  1. 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]
  2. 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]
  3. Nodes SHALL exit commissioning mode after 20 failed commission attempts (see Section 5.5, “Commissioning Flows”). [CM100 for T101, T112]
  4. Devices SHALL include a Device Attestation Certificate and private key, unique to that Device. [CM23 for T22, T24, T34, T86]
  5. 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].
  6. 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]

  1. 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

  1. Devices and Nodes SHALL have a factory reset [CM15 for T16, T17, T79, T82]
  2. 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

  1. 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]
  2. 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]
  3. 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

  1. 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]
  2. 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]
  3. 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]
  4. 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]
  5. Devices SHALL use non-repeating initialization vectors for a given session [CM78 for T81]

 

13.6.2.  Commissioning

  1. Manufacturers SHOULD control the number of DACs issued under their Vendor [CM24 for T23, T34]
  2. 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]
  3. 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]
  4. 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]
  5. A Commissioner or Administrator SHOULD only add Root Certificates that it trusts to a Node. [CM36 for T153]
  6. A device manufacturer SHOULD implement Basic Commissioning Method only for devices that adequately secure the Passcode. [CM154 for T173]

 

13.6.3.  Firmware

  1. 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]

  1. 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

  1. 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

  1. 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

  1. 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

  1. 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

  1. 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

  1. 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]
  2. 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]
  3. 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]

  1. Vendors SHOULD protect DCL private keys in Hardware Security Module (HSM) equipped servers. [CM167 for T168, T186]
  2. 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.

 

 

 

 

 

Adsense

 

 WiFi IoT Module

 

www.mxchip.com

 

 

 Bluetooth Module

www.feasycom.com

 

 

 5G/LTE/CAT-M1/NB-IoT

 

www.simcom.com

 

Viewed Page List