<h3 style="text-align:center;">Chapter 4 - Part 6</h3><h3 style="text-align:center;">Message counters</h3>Message countersAll messages contain a 32-bit message counter assigned by the sender of the message. Message counters are allocated sequentially by uniformly incrementing the counter value maintained by the message sender. Message counters serve several purposes:<ul><li style="text-align:justify;">Duplicate message detection</li><li style="text-align:justify;">Confirmation message</li><li style="text-align:justify;">Single number encryption</li><li style="text-align:justify;">Prevent replay</li></ul>Types of message countersAll nodes implement three 32-bit global counters to sell message counters for certain types of messages:<ul><li style="text-align:justify;">Global unencrypted message counter</li><li style="text-align:justify;">Global group encrypted data message counter</li><li style="text-align:justify;">Universal group encrypted control message counter</li><li style="text-align:justify;">Secure session message counter</li></ul>Setting up the message counterAll message counters must be initialized with a random value using Crypto_DRBG(len = 28) + 1 initial). Message counters are initialized to a random number to increase the difficulty of traffic analysis attacks by making it harder to determine how long a particular session is open. The random initialization ranges from 1 to 228 to maximize initial entropy while maintaining a large majority of the range for actual counter values (approximately 228&nbsp;–&nbsp;232).&nbsp;Global unencrypted message counterAll nodes MUST implement an unencrypted message counter, which is used to generate counters for unencrypted messages.&nbsp;Global group encrypted message counterThe global group encrypted message counter is used to generate a counter for encrypted messages using group keys. There are two such counters:<ul><li style="text-align:justify;">The global group encrypted data message counter is used to encrypt ordinary data messages encrypted with a group key.</li><li style="text-align:justify;">The global group encrypted control message counter is used to encrypt control messages encrypted with a group key.</li></ul>Secure session message counterThe Secure Session Message Counter is an ephemeral 32-bit per-session counter used to encrypt each encrypted message using an associated session key. Each peer in a secure unicast session must maintain its own message counters, with independent counters used for each unique session. Session message counters must exist as long as the associated security session is active. A node SHOULD randomize the initial value of this counter on session creation in the ``Initialize Message Counter'' section.&nbsp;Non-encrypted message counterIn the context of encrypted messages, message counters act as single numbers for the encryption algorithm and ensure that each message is encrypted uniquely&nbsp;way. The uniqueness of the encrypted message counter is critical to message confidentiality because the encryption algorithm makes decryption of messages trivial for eavesdropping if an attacker can find two different messages with the same message counter that were encrypted using the same key. Specifically, an attacker can XOR two different messages that share the same key and prime to obtain a "blocking key" that can be used to decrypt any message that uses that key and prime.&nbsp;Prevent replaying and detecting duplicate messagesIn addition to their role as single-number encryption, message counters also serve as a means of detecting repeated receipt of a message. Repeated messages can occur for a number of reasons: excessive logging, network latency, malicious attack, or network error. For example, a replay may occur when a sender sends a message after not receiving an acknowledgment, or because a malicious third party tries to replay an old message to gain an advantage.&nbsp;Message receiving statusThe state given by a node regarding the messages it has received from a particular peer is called the message receiving state. Nodes use this state information to determine whether a newly arrived message is a duplicate of a previous message. Message receipt status is maintained on a per-peer or per-session basis, depending on the type of message encryption used.&nbsp;Using message receiving mode for encrypted messages&nbsp;&nbsp;<figure class="image"><img src="https://platform.iotsmile.com/assets/uploads/3c5f53590b8e5202--aec73a68--141cecde--b92f6689--c4bf33934222275cd011654d8207132.png"><figcaption>Figure 1- Message receiving status</figcaption></figure>&nbsp;<ul><li style="text-align:justify;">The algorithm for querying and updating the status of message receipt is slightly different depending on whether the system tracks the receipt of encrypted or unencrypted messages and consists of the following two types:</li><li style="text-align:justify;">Message counters with a maximum (does not reset to zero after reaching the maximum value)</li><li style="text-align:justify;">Message counter with rotation (after reaching the maximum value it resets to zero)</li></ul>&nbsp;Using message receiving status for unencrypted messagesFor unencrypted messages, the message tracking and duplicate detection algorithms are similar, but for encrypted messages using the&nbsp;“message counters with shift” section. This reflects the fact that duplicate detection of unencrypted messages is not done for security reasons, but rather to detect duplicates caused by network errors (such as missing an&nbsp;ACK), which are usually more limited in time. Allows message receivers to store counters in RAM.&nbsp;Setting up the message receiving status<ul><li style="text-align:justify;">To initialize the message, receive state for the peer node ID, initial maximum max_message_counter, message type (control or data), encryption level (encrypted or unencrypted), and encryption key (for any encryption level except unencrypted) receive state fields The message should be set as follows:</li><li style="text-align:justify;">The ID of the peer node must refer to the ID of the peer node.</li><li style="text-align:justify;">The type of message must be the same as the type of message given.</li><li style="text-align:justify;">The encryption level must be the same as the given encryption level.</li><li style="text-align:justify;">If the encryption level is not encrypted, the encryption key MUST refer to the given key.</li><li style="text-align:justify;">The max_message_counter should be set to the given max_message_counter.</li><li style="text-align:justify;">The message counter bitmap should all be set to 1, indicating that only new messages with</li><li style="text-align:justify;">A counter greater than max_message_counter should be accepted.</li></ul>In the fourth chapter of the main document of the Matter standard, the topics of message, communication and protocols are discussed in detail. Due to the length of these topics, in the rest of this lesson, we will only deal with the general topics raised and finish this section.&nbsp;message processing<ul><li style="text-align:justify;">The message processing section consists of two sections: sending and receiving messages.</li></ul>Message securityIn this section, the following are discussed:<ul><li style="text-align:justify;">Data confidentiality and integrity with data source authentication parameters</li><li style="text-align:justify;">Security processing of outgoing messages</li><li style="text-align:justify;">Security processing of incoming messages</li></ul>message privacy protection<ul><li style="text-align:justify;">Data confidentiality and integrity with data source authentication parameters</li><li style="text-align:justify;">Security processing of outgoing messages</li><li style="text-align:justify;">Security processing of incoming messages</li></ul>Message exchange<ul><li style="text-align:justify;">Privacy key</li><li style="text-align:justify;">Privacy singularity</li><li style="text-align:justify;">Privacy processing of outgoing messages</li><li style="text-align:justify;">Privacy processing of incoming messages</li></ul>Secure channel protocol<ul><li style="text-align:justify;">Secure Channel Protocol messages</li><li style="text-align:justify;">Parameters and constants</li></ul>Message Validation Protocol (MRP)<ul><li style="text-align:justify;">Secure channel trust protocol</li><li style="text-align:justify;">Message Validation Protocol (MRP)</li></ul>Unicast communication<ul><li style="text-align:justify;">Meeting phase</li><li style="text-align:justify;">Application data phase</li></ul>Create session layer<ul><li style="text-align:justify;">Create authentication session with password (PHASE)</li><li style="text-align:justify;">Overview of the protocol</li></ul>Group communication<ul><li style="text-align:justify;">Group cast session context</li><li style="text-align:justify;">Send a group message</li><li style="text-align:justify;">Receive group messages</li></ul>group key management<ul><li style="text-align:justify;">Operational groups</li><li style="text-align:justify;">Extracting the operating group key</li><li style="text-align:justify;">Time keys</li><li style="text-align:justify;">Distribution of key items</li></ul>Message Counter Synchronization Protocol (MCSP)<ul><li style="text-align:justify;">Message counter synchronization methods</li><li style="text-align:justify;">Peer group status</li><li style="text-align:justify;">MCSP messages</li><li style="text-align:justify;">Asynchronous message processing</li><li style="text-align:justify;">Message counter synchronization exchange</li><li style="text-align:justify;">Message counter synchronization session content</li><li style="text-align:justify;">Sequence diagram</li></ul>Bluetooth Transmission Protocol (BTP)<ul><li style="text-align:justify;">BTP session interface</li><li style="text-align:justify;">BTP frame formats</li><li style="text-align:justify;">BTP GATT service</li><li style="text-align:justify;">Parameters and constants</li><li style="text-align:justify;">Bluetooth SIG considerations</li></ul>We hope that by studying the presented lessons, you have learned everything you need to know the subject of standard Matter.To study and get more information about this standard, you can visit the CSA website and take a closer look at the main document of the Matter standard.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

The Matter Communication Standard

Chapter 4 - Part 6 Message counters

<h3 style="text-align:center;">Chapter 4 - Part 5</h3><h3 style="text-align:center;">Discover Gateway</h3>&nbsp;In the previous lesson, we examined operational discovery, and continuing the principles of learning the Matter protocol, we intend to teach the topic of operational discovery in this lesson.&nbsp;Gateway discoveryA gateway may initiate the setup process by discovering gateways on the network. This may be done using the GitHub discovery described in this section.With gateway discovery, a gateway, after interacting with a user, may discover gateways on the network and obtain a list of information for each of them, which may include vendor ID, product ID, and device name. A gateway with a user interface, such as a TV set, thermostat, or video player, may display a list of discovered items for the user to choose from. Once selected, Gateway may use the User Directed Commissioning Protocol with Gateway to indicate that the User has selected it to set up Gateway. Therefore, the records of the GitHub discovery service enable a form of the&nbsp;“doorbell” protocol to allow GitHub to request startup.&nbsp;ExamplesThe following examples simulate the theme GitHub ads that exist on the network. Examples are shown using the dns-sd command-line test tool and the avahi command-line test. The dns-sd command line test tool is included in all versions of macOS. It installs as a DOS command with Bonjour for Windows and is available on Linux by installing the mDNSResponder package. The avahi command-line testing tool from the Avahi project is available for most Linux distributions.Consider a device on Wi-Fi that uses the MAC address of the 48-bit device B75AFB458ECD as its hostname. DNS-SD records for can be set as follows:&nbsp;<figure class="image"><img src="https://platform.iotsmile.com/assets/uploads/52c5a33fea00d605--a2a296bf--1415e7dd--b9e94a21--f2daa012fc25c1a76d61eac58386309.png"><figcaption>Figure 1- DNS-SD records</figcaption></figure>or<figure class="image"><img src="https://platform.iotsmile.com/assets/uploads/d77e4b8c23e66a0b--aaa293e7--1410ebdb--b8ed452f--f8dda71ff82ec5a0666de4c845692.png"><figcaption>Figure 2 - Another form of DNS-SD records</figcaption></figure>&nbsp;Common TXT key/value pairsTXT records provided during Gateway, Operational, and Gateway discovery may contain the following optional key/value pairs common to each discovery method:The optional SII key indicates the SLEEPY_IDLE_INTERVAL node. This key may optionally be provided by a node to override defaults. If the key is not included or is invalid, the node querying the service record MUST use the default SED parameter value. The SII value is an unsigned integer with units of milliseconds and&nbsp;must be encoded as a variable-length decimal number in ASCII encoding, omitting leading zeros. SII value should not exceed 3600000 (1 hour per millisecond)For example: SII=5300 to override the initial retry interval value to 5.3 seconds.The optional SAI key indicates the SLEEPY_ACTIVE_INTERVAL node. This key may optionally be provided by a node to override SED defaults. If the key is not included or is invalid, the service record query node MUST use the default MRP parameter value. The SAI value is an unsigned integer with units of milliseconds and must be encoded as a variable-length decimal number in ASCII encoding, omitting leading zeros. SAI value should not exceed 3600000 (1 hour per millisecond)Example: SAI=1250 to override the active retry interval value to 1.25 secondsThe optional T key indicates whether the node supports TCP. This key may optionally be provided by a node that does not support TCP. If the key is not included or is invalid, the node querying the service record MUST assume the default value of T=0, indicating that TCP is not supported. The T key, if present, must have one of two valid values: '0' to indicate “TCP is not supported ”, or “1 ” to indicate “TCP is supported”.Example: T=1 for TCP announcement supported by advertising node.&nbsp;Message frame formatThis section describes the encoding of the Matter message format. The Matter message format provides flexible support for various communication paradigms, including secure unicast sessions, multicast group messaging, and session creation. The process of encrypting Matter messages is the same in all communication modes and assumes that symmetric keys are shared between communicating parties. Unencrypted messages are only used for protocols that initiate secure messages, such as session establishment.Matter messages are used by Matter applications as well as the Matter protocol stack itself to transfer application-specific data and/or commands. The Protocol section of a Matter message contains the Protocol Identifier and the Protocol Opcode, which specify both the semantic meaning of the message and the structure of any associated application payload data. Matter messages also carry an Exchange Identifier that associates the message with a specific exchange taking place between two nodes. Finally, certain types of Matter messages can convey information that acknowledges receipt of a previous message. It is used as part of the Message Reliability Protocol to provide guaranteed delivery of messages over unreliable transmission.The structure of Matter messages is as follows:Note: The sign [] indicates that the field is optional.The message payload in a Matter message must contain the protocol message in the following format:&nbsp;<figure class="image"><img src="https://platform.iotsmile.com/assets/uploads/e5b71445f8c99809--aaa5bafd--141ce1dc--bae0462b--f9d9ac11f52acca0646ae5cf2424794.png"><figcaption>Figure 3 - Protocol message in a Matter message</figcaption></figure>&nbsp;Description of the message header field<ul><li style="text-align:justify;">Message length (16 bits)</li><li style="text-align:justify;">Message flags (8 bits)</li><li style="text-align:justify;">Session ID (16 bits)</li><li style="text-align:justify;">Security flags (8 bits)</li><li style="text-align:justify;">message counter (32 bits)</li><li style="text-align:justify;">source node ID (64 bits) destination node ID</li><li style="text-align:justify;">message plugin variable</li></ul>&nbsp;Description of the footer part of the message<ul><li style="text-align:justify;">Checking the integrity of the message (variable length) is done in this part.</li></ul>&nbsp;Protocol header field description<ul><li style="text-align:justify;">flag exchange (8 bits)</li><li style="text-align:justify;">Protocol Opcode (8 bits)</li><li style="text-align:justify;">exchange ID (16 bits)</li><li style="text-align:justify;">Protocol ID (16 bits)</li><li style="text-align:justify;">protocol vendor ID (16 bits)</li><li style="text-align:justify;">Confirmed message counter (32 bits)</li><li style="text-align:justify;">Secure extensions (variable)</li><li style="text-align:justify;">program load (variable length)</li></ul>&nbsp;Message size requirementsSupport for IPv6 fragmentation is not mandatory in Matter, and the expected MTU supported is 1280 bytes, which is the minimum IPv6 requirement. Therefore, all messages, including transport headers, must fit within that minimum IPv6 MTU. This message size limit should apply to UDP transport. A message received via UDP that exceeds this message size limit will not be processed. Messages sent over TCP or BTP over BLE transport may exceed the message size limit if both nodes are capable of supporting a larger message size.&nbsp;In this lesson, we got acquainted with the topic of Gateway and learned its various examples. In the next section, we will discuss the topic of message counters and the details of this issue. Stay with us.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

Chapter 4 - Part 5  Discover Gateway

<h3 style="text-align:center;">Chapter 4 - Part 4</h3><h3 style="text-align:center;">operational discovery</h3>&nbsp;In the continuation of the topic of the principles of learning the Matter protocol, in this lesson we will teach the topic of operational discovery.&nbsp;&nbsp;Operational discoveryFor Matter nodes already deployed on a Matter Fabric, instead of assuming a fixed IPv6 address and port for the lifetime of the product, dynamic discovery of operational Matter nodes is used at runtime. This is done with the goal of greater flexibility, so that the underlying IPv6 network can grow and evolve over time as needed without breaking Matter's functionality.&nbsp;The name of the&nbsp;operational&nbsp;exampleFor operational Matter discovery, the DNS-SD instance name is constructed from a compact 64-bit Fabric ID and a 64-bit Node ID (as assigned by Gateway). Each is expressed as a fixed-length sixteen-character hexadecimal string, encoded as ASCII text (UTF-8) using uppercase letters, separated by spaces.&nbsp;Compact Fabric IDIn order to reduce the very large size of a full Fabric reference that must be used as a scope structure in the instance name, a compressed 64-bit version of the full Fabric reference should be used. The calculation of compressed Fabric ID should be as follows:&nbsp;<figure class="image"><img src="https://platform.iotsmile.com/assets/uploads/8bdcb2542a2f150f--a25b2739--1411e9d7--88335de3--5e1be6173b65e4d2342fa50d1560996.png"><figcaption>Figure 1 - Compact Fabric ID calculation</figcaption></figure>&nbsp;Type of operational servicesThe DNS-SD service type [RFC 6335] for operational discovery of Matter is _matter. _top. Note that the _top string is a header inherited from the original DNS SRV specification and does not necessarily mean that the advertised application layer protocol runs over TCP only.&nbsp;Operating service domain and host nameFor link-local Multicast DNS, the service domain must be local. For unicast DNS like the one used in Thread, the service domain should be automatically configured by Thread's border router. For DNS-SD, a hostname is required in addition to the instance name. The target hostname must be constructed using one of the available link layer addresses, such as a 48-bit device MAC address (for Ethernet and Wi-Fi) or a 64-bit Extended MAC address (for Thread).If a privacy-preserving device performs MAC address randomization, the target hostname SHOULD use the privacy-preserving random version, and the hostname record SHOULD be updated each time the underlying link layer address is rotated.&nbsp;Operational discovery service recordsAfter discovery, IPv6 addresses are returned to AAAA records and key/value pairs in DNS-SD TXT records. If no key is defined, the TXT record may be omitted. Nodes MUST publish AAAA records for all available IPv6 addresses on which they wish to accept operational messages.&nbsp;Functional recommendationsTo improve the overall performance of operational exploration, especially in large installations, the following recommendations should be considered:&nbsp;1. Nodes SHOULD store the last known IPv6 address and port for each peer node they interact with from the SRV record and resolved using DNS-SD to save the cost of network lookup operations if not needed. Save running time. When the IPv6 address and port for a peer node are unknown, or an attempt to communicate with a peer node at its last known IPv6 address and port appears unsuccessful within the expected network round-trip time, then a node must perform runtime discovery in parallel to determine whether the target node has obtained a new IPv6 address and/or port.&nbsp;2. Nodes SHOULD respond to non-specific service enumeration requests for the General Operational Discovery Matter service type, but these queries should not be used in routine operations and are recommended to be used only for diagnostic purposes or to determine new cases. When used, it is recommended that the enumeration service use the _I&lt;HHHH&gt; Fabric subtype to enumerate only the desired nodes in the fabric of interest in the local network. Additionally, known response suppression [RFC 6762] SHOULD be used in such cases to minimize the number of unnecessary responses to such a request.&nbsp;3. When resolving another node's operational service record, a node SHOULD use an SRV query for the operational service instance in question, rather than performing a global enumeration of all nodes. This recommendation reduces the amount of multicast traffic generated on the link when using Multicast DNS and reduces the delay in successful service resolution.&nbsp;4. Because proxy DNS-SD service discovery may be used in a given network, and service record keeping is expected from DNS-SD clients, nodes SHOULD NOT use DNS-SD as an operational liveness determination method. This is because there may be old records that have not yet expired that may still be available after a node becomes unavailable.&nbsp;Examples of operational discovery DNS-SDThe following example simulates a Matter node that advertises its availability for control via the Matter protocol. Examples are shown using the dns-sd command line test tool and the avahi command line test tool. The dns-sd command line test tool is included in all versions of macOS. It installs as a DOS command with Bonjour for Windows and is available on Linux by installing the mDNSResponder package. The avahi command-line testing tool from the Avahi project is available for most Linux distributions.This example is provided for illustrative purposes only. Nodes and controllers do not use command-line testing tools for advertising and discovery. Real Matter nodes and controllers use the appropriate DNS-SD APIs in their programming languages of choice.&nbsp;In this lesson, we examined the topic of operational exploration in detail. In the next lesson, we will discuss other issues raised in the fourth chapter of the main document of the Matter standard. Stay with us.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

Chapter 4 - Part 4
operational discovery


Chapter 4 - Part 4 section operational discovery

<h3 style="text-align:center;">Chapter 4 - Part 3</h3><h3 style="text-align:center;">Review of TXT key functions</h3>&nbsp;In the continuation of the fourth chapter with the topic of secure channel, in this section we will examine the TXT records and learn about the types of TXT key applications. Be with the moon.&nbsp;TXT records&nbsp;After discovery, IPv6 addresses are returned in the AAAA records and key/value p in the DNS‑SD TXT record.&nbsp;Nodes SHALL publish AAAA records for all their available IPv6 addresses.TXT records available for Commissioning node discovery contain typical record key/value pairs.&nbsp;TXT key for distinguisher (D)The D-key MUST provide the full 12-bit identifier for the bootable node and must be present in the DNS-SD TXT record.The distinguisher value must be encoded as a variable-length decimal number in ASCII text, with a maximum of four digits, excluding leading zeros.Any D key with a value that does not match the above should be ignored.&nbsp;TXT key for Vendor ID and Product ID (VP)If the optional VP key is present, it may provide vendor ID and product ID information for the device. A seller may not include it at all for privacy reasons.If the VP key is present, it may appear in two forms:1. VP=123 gives the vendor ID.2. VP=123+456 gives vendor id + product id.Both the Vendor ID and the Product ID must be expressed as variable-length decimal numbers, encoded as ASCII text, with leading zeros omitted, and a maximum length of 5 characters each to match their 16-bit numeric range.If the product ID is present, it must be separated from the vendor ID using a "+" character.If a VP key exists without a product ID, the value must contain only the vendor ID alone, without the "+" character.If a VP key is present, the value must contain at least the vendor ID.If the VP key exists, it must not have an empty value.&nbsp;TXT key for commission mode (CM)The CM (Commission Mode) key should indicate whether the record publisher is currently in startup mode and available for immediate startup. In startup mode, the value corresponding to the CM key represents the password source.There are four legal modes:1. The absence of the CM key should indicate the value 0 (CM=0).2. The CM=0 key/value pair should indicate that the publisher is not currently in startup mode.3. The key/value pair CM=1 should indicate that the publisher is currently in startup mode and needs to use the password provided by Gateway to start up.4. The key/value pair CM=2 SHALL indicates that the issuer is currently in commissioning mode and requires the use of a dynamically generated password associated with the verifier using the Open Commissioning Window command. sent to the device.&nbsp;TXT key for device type (DT)The optional DT key may provide the primary device type of the publisher. If the device combines multiple device types, the manufacturer must select the device type identifier of the primary function of the device for which the device wishes to be identified. If present, it must be encoded as a variable-length decimal number in ASCII text, with leading zeros removed.&nbsp;TXT key for device name (DN)The optional DN key may provide the advertised name of the device. If present, it must be encoded as a valid UTF-8 string with a maximum length of 32 bytes.If provided, the source of this value MUST be user-editable and its use clearly specified for in-network advertising, and the value stored in the Node Label attribute MAY be the cluster's basic node information.&nbsp;TXT key for device rotary identifier (RI)The optional RI key may provide the rotary identifier of the device.If present, the value associated with the RI key MUST contain the bytes of the rotating device identifier string, each byte represented as 2-digit hexadecimal.The resulting ASCII string must not exceed 100 characters, which means a rotating device ID of up to 50 octets.&nbsp;TXT key for pairing instructions (PH)The optional PH key may provide a pairing hint. If present, it should be encoded as a variable-length decimal number in ASCII text, with leading zeros removed.&nbsp;TXT key for pairing instructions (PI)The optional PI key may command pairing, and the meaning of this key depends on the value of the PH key. If present, the value must be encoded as a valid UTF-8 string with a maximum length of 128 bytes.&nbsp;ExamplesThe following examples simulate a node in startup mode that advertises its availability for startup.Examples are shown using the dns-sd and avahi command-line testing tools. The dns-sd command line test tool is included in all versions of macOS. It is installed as a DOS command with Bonjour for Windows and is available on Linux by installing the mDNSResponder package. The Avahi command-line tools package from the Avahi project is available for most Linux distributions.These examples are provided for illustrative purposes only. Real Matter gateways and endpoints do not use command-line testing tools for advertising and discovery. Real Matter gateways and endpoints use the appropriate DNS-SD APIs in their respective programming languages of choice.Consider a device on Wi-Fi that uses the 48-bit device MAC address B75AFB458ECD as its hostname and the value DD200C20D25AE5F7 as its orderable service instance name. DNS-SD records for it can be set as follows:&nbsp;dns-sd -R DD200C20D25AE5F7 _matterc. _udp, _S3, _L840, _CM. 11111 D=840 CM=2oravahi-publish-service --subtype=_S3._sub._matterc._udp --subtype=_L840._sub._matterc._udp DD200C20D25AE5F7 --subtype=_CM._sub._matterc._udp _matterc._udp 11111 D=840 CM=2&nbsp;The short discriminator can be filtered through the _S3 subtype and algorithmically through the D=840 TXT key.The long delimiter can be filtered via the _L840 subtype and directly via the D=840 TXT key.&nbsp;In this lesson, we examined the functions of the TXT key, and in the next section, we will be with you with the continuation of the fourth chapter and the topic of the secure channel.&nbsp;

Chapter 4 - Part 3
Review of TXT key functions


Chapter 4 - Part 3  Review of TXT key functions

<h3 style="text-align:center;">Chapter 4&nbsp;—&nbsp;Part 2</h3><h3 style="text-align:center;">Commissionable Node Discovery</h3>&nbsp;In the continuation of the fourth chapter and the subject of the secure channel, in this section we intend to have a more comprehensive look at the topic of Commissionable node detection.The discovery section actually describes the advertising and discovery services for the Matter protocol and is used in the following areas:• Commissionable Node Discovery• Operational Discovery• Commissioner Discovery• User Directed Commissioning&nbsp;Service Advertisement and Discovery for Matter uses standard DNS-based service discovery. The Matter protocol does not require any changes to the IETF standard DNS-SD. In fact, using DNS-SD means that the IPv6 unicast address and port of the provided service are discovered, and Matter does not need a pre-assigned fixed port. It is also possible to run several instances of the Matter software in one device; Because each instance will have its own dynamic port instead of trying to use the same pre-allocated static port.Since Matter protocols must support at least IPv6, Matter software that discovers other Matter instances must process IPv6 address (DNS AAAA) records as well as IPv4 address DNS A records.For this reason, where possible in the underlying service discovery API, Matter software that advertises the availability of a service MUST indicate that the service's announcements and responses only contain IPv6 address records, not IPv4 address records.Where supported in the underlying service discovery API, Matter software using Multicast DNS to advertise the availability of a service SHOULD indicate that notifications and responses for this service should only be made over IPv6.For Thread mesh networks, where excessive use of multicast is harmful [RFC 7558], DNS-SD uses Unicast DNS instead and uses the Thread Service Registry capabilities in draft-lemon-stub-networks.Conceptually, the DNS-SD [RFC 6763] information being sent is the same as when DNS Multicast [RFC 6762] is used, except that the information is sent in multicast packets to and from every other node in the same domain rather than in multicast packets. Broadcasts are transmitted in unicast packets from a designated service registry.Using the Service Registration Protocol (SRP) and an advertising proxy (AdProx) running on the Thread border router, Matter nodes in a Thread network can be reached by other Matter nodes on an adjacent Ethernet or Wi-Fi link, without the cost of using multicast. Discovered on Thread mesh.When Matter nodes send short-term requests to its other nodes, the response is sent to the source IPv6 address and port of the request. This is despite the fact that by issuing long-term requests to other requester nodes, the IPv6 address or port has been changed, so the responder may discover the current IPv6 address and the initiator port to send.&nbsp;Commissionable Node DiscoveryThe Matter protocol family supports UDP and TCP for setting up gateways that are already defined on the client's IP network, as well as for setting up the end device in connection with the Wi-Fi Soft-AP.For these gateways, Matter bootable node discovery is performed using the IETF Standard DNS-Based Service Discovery (DNS SD) [RFC 6763].To discover a Commissionable Matter node in cases such as already-on-network and Soft-AP, the DNS-SD instance name must be a 64-bit temporary, dynamically unique identifier, chosen as a fixed-length sixteen-character hexadecimal.When a Node receives either the OpenCommissioningWindow or the OpenBasicCommissioningWindow command, the node only needs to be represented on the IP network using the corresponding DNS SD attributes.&nbsp;Host Name ConstructionIn DNS-SD, in addition to the instance name, the hostname is also required. The target hostname must be constructed using one of the available link layer addresses, such as a 48-bit device MAC address for Ethernet and Wi-Fi or a 64-bit Extended MAC address for Thread.If a privacy-preserving device performs MAC address randomization, the target hostname should use the privacy-preserving random version, and the hostname record SHOULD be updated each time the underlying link layer address is rotated. Note that it is legal to reuse the same hostname on more than one interface, even if the underlying link-layer address does not match the hostname on that interface, because the purpose of using a link-layer address is to ensure uniqueness.&nbsp;Extended DiscoveryA Matter Commissionee that advertises endpoint discovery service records is not necessarily in a state that allows startup, which is called the "in startup" mode. On the other hand, the end node discovery advertisement is known as "expanded discovery" when it is not in launch mode. Extended discovery is only allowed for DNS-SD advertisements and is not allowed for other forms of device discovery such as BLE device discovery and Wi-Fi ad hoc access point discovery. To protect customer privacy on public networks, Matter Gateway must provide a way for the customer to set a time period in device discovery (Extended Discovery) or otherwise disable it.&nbsp;Commissioning Subtypes1. _L&lt;dddd&gt;, where &lt;dddd&gt; provides the full 12-bit discriminator, encoded as a variable-length decimal number in ASCII text, omitting any leading zeroes. 2. _S&lt;dd&gt;, where &lt;dd&gt; provides the upper 4 bits of the discriminator, encoded as a variable-length decimal number in ASCII text, omitting any leading zeroes. 3. _V&lt;ddddd&gt;, where &lt;ddddd&gt; provides the 16-bit Vendor ID, encoded as a variable-length decimal number in ASCII text, omitting any leading zeroes. 4. _T&lt;ddd&gt;, where &lt;ddd&gt; provides the device type identifier for the device, encoded as a variable length decimal number in ASCII (UTF-8) text, omitting any leading zeroes. In case the device combines multiple device types, the manufacturer SHOULD choose the device type identifier of the primary function of the device for which the device wishes to be discoverable.5. _CM, which represents "currently in Commissioning Mode"&nbsp;TXT RecordsAfter discovery, IPv6 addresses are returned in the AAAA records and key/value pairs are returned in the DNS‑SD TXT record.Nodes SHALL publish AAAA records for all available IPv6 addresses upon which they are willing to accept Matter commissioning messages.TXT records available for Commissionable Node Discovery include the common TXT record key/value pairs.In this section, we learned how to discover a Commissionable&nbsp;node and its principles. In the next section, we will continue discussing the safe channel.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

Chapter 4 — Part 2
Commissionable Node Discovery


Chapter 4 - Part 2  Commissionable Node Discovery

<h2 style="text-align:center;">Chapter 4 - Part 1</h2><h2 style="text-align:center;">Messages and IPv6 reachability</h2>&nbsp;Continuing the topic of the principles of learning the Matter protocol, in the fourth chapter we will discuss the training of the secure channel. Since this chapter consists of many parts, therefore, for the ease of teaching, we divide the fourth chapter into several parts and teach it. Therefore, in the first part of the eighth chapter, we examine the topic related to messages and IPv6 accessibility. Stay with us.First, we must state that the secure channel and message layer allow nodes to communicate securely with each other by creating a fixed network service platform. During the setup process and unicast communication, a discovery mechanism is provided to determine the matching IPv6 addresses and operational parameters. Secure session establishment mechanisms are provided using certificates (CASE) or shared passwords (PASE).&nbsp;MessagesCommunication is created using messages and includes two categories: secure communication and insecure communication.Each message has two parts: a Session Type part and a Session ID part. In this way, it is determined whether this message is secure or not. Each message has a message counter field to uniquely identify the message for security purposes.Unsecured communications are limited to<ul><li style="text-align:justify;">Discovery</li></ul>which does not use the Matter message format.<ul><li style="text-align:justify;">User Directed Commissioning (UDC)</li></ul>which uses insecure messages to start the boot process.<ul><li style="text-align:justify;">Session establishment</li></ul>which uses unsecured messages to establish a CASE or PASE session.&nbsp;Message typesMessages are defined in two types: control message and data message. Most of these messages are data messages. Control messages are reserved for internal protocols such as MCSP. The format of both message types is the same, but they each use separate message counter domains to work securely on the same security key.&nbsp;Message TransportsMessages have limited sizes and are sent as individual packets via the supported transports listed below:<ul><li style="text-align:justify;">UDP&nbsp;</li></ul>It transmits the messages as a separate datagram.<ul><li style="text-align:justify;">TCP&nbsp;</li></ul>It transmits each message with a predetermined length and performs fragmentation and reassembly if necessary.<ul><li style="text-align:justify;">BTP&nbsp;</li></ul>Each message is transmitted over BLE as a separate SDU, segmentation is performed, and BTP is provided as a transport protocol to boot.&nbsp;Message ExchangesEach message provides an exchange layer for tracking related messages that form small, discrete transactions. The exchange layer provides this transaction tracking facility for the interaction model layer, and provides a means of multiplexing multiple concurrent transactions within a given underlying session. The "message layer stack" is shown in the figure below:&nbsp;IPv6 ReachabilityIn this section, IPv6 network configuration requirements are explained for its access between nodes. As explained in the network topology chapter, a Matter network may consist of one or more IPv6 networks.In a single network configuration, all Matter nodes are connected to the same IPv6 link and may consist of a connected Wi-Fi / Ethernet network. When all Matter nodes are connected to the same Wi-Fi / Ethernet network, no additional IPv6 network infrastructure is required.In a multi-network configuration, a Matter network usually consists of an infrastructure network and one or more subnets. Unlike an infrastructure network, subnetworks do not act as transit networks. Typically, the infrastructure network is a bridged Wi-Fi / Ethernet network, and Thread networks are subnets. A micro router connects a micro network to an infrastructure network and provides IPv6 access between the two networks.<ul><li style="text-align:justify;">Stub Router Behavior</li></ul>In a multi-network configuration, infrastructure and subnets require routable IPv6 addresses to communicate between networks. A routable IPv6 address must have a global domain (eg GUA or ULA) and must be constructed out of the on-link advertised prefix. It should be noted that "on-mesh prefix" is equivalent to "on-link prefix" in Wi-Fi/Ethernet. Stub routers must advertise access to all routable prefixes in the adjacent network.<ul><li style="text-align:justify;">Matter Node Behavior</li></ul>Matter nodes must configure a local IPv6 address. Also, nodes must support the configuration of at least three routable IPv6 addresses (in addition to link-local and, in the case of Thread, local addresses).&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

Chapter 4 - Part 1- Messages and IPv6 reachability

Chapter 4 - Part 1  Messages and IPv6 reachability

Chapter 3 &nbsp;- Cryptographic Primitives&nbsp;In this chapter, we are going to introduce the types of encryption primitives, algorithms and protocol building blocks used in the Matter communication standard and provide a brief yet practical explanation for each of these.Given a version of the message format, cryptographic primitives are mapped to specific instances. There is no cryptographic negotiation in this protocol: a copy of the message format has a cipher suite defined in this chapter.In each section, the cryptographic primitives are generally defined, along with specific mappings to specific instances of these cryptographic primitives, for version 1.0. This chapter can also be used as a guide on which cryptographic primitives should be supported by a device. It is necessary to pay attention to the fact that not all devices are required to support all of them. For example, a device may not require the initial (Crypto_PBKDF); Because the values based on this operation in some cases can be calculated and stored in advance during the device manufacturing process. In this chapter, the proposed functional mapping is normative according to the values calculated by the functions, but it is considered informative according to the way the functions are connected in the implementations. For example, a function that returns both a Boolean to indicate success and a value if the operation succeeds can be implemented using exception mechanisms instead of returning a Boolean.The cryptographic primitives discussed in this article operate on data local to the host. Where more complex data types exist and their external representation is applicable, this chapter addresses coding details. Simple multi-byte data types with no additional context are assumed to be in host byte order when used internally for a procedure, unless otherwise specified.&nbsp;Cryptographic methods<ul><li>Deterministic Random Bit Generator (DRBG)</li></ul>This protocol relies on random numbers for many security purposes. For example, random numbers are used in generating secret keys, counters, cryptographic signature generation random secrets, etc.<ul><li>True Random Number Generator (TRNG)</li></ul>A TRNG (aka. Entropy Source) is required to provide an entropy seed as an input to the DRBG algorithm.<ul><li>Hash function (Hash)</li></ul>Crypto Hash () computes the cryptographic hash of a message.&nbsp;<ul><li>Keyed-Hash Message Authentication Code (HMAC)</li></ul>Crypto_HMAC () computes the cryptographic keyed-hash message authentication code of a message.&nbsp;<ul><li>Public Key Cryptography</li></ul>Matter specifies the following scheme and parameters for public key cryptography:<ul><li style="text-align:justify;">Group</li><li style="text-align:justify;">Key generation</li><li style="text-align:justify;">Signature and verification (Include Signature and Signature verification)</li><li style="text-align:justify;">ECDH</li><li style="text-align:justify;">Certificate validation</li><li style="text-align:justify;">Time and date considerations for certificate path validation</li></ul>&nbsp;<ul><li>Data Confidentiality and Integrity</li></ul>Symmetric block ciphers are used to provide message security. All unicast and multicast messages between Nodes requiring protection for confidentiality and integrity with data origin authentication SHALL use Authenticated Encryption with Associated Data (AEAD) as primitive to protect those messages:<ul><li>Generate and encrypt</li><li>Generate and encrypt</li></ul>&nbsp;<ul><li>Message privacy</li></ul>Message privacy is implemented using a block cipher in CTR mode:<ul><li>Privacy encryption</li><li>Privacy decryption</li></ul>&nbsp;<ul><li>Key Derivation Function (KDF) Matter specifies the following key derivation function to generate encryption keys</li></ul>&nbsp;<ul><li>Password-Based Key Derivation Function (PBKDF) Matter specifies the following password-based key derivation function to compute a derived key from a cryptographically weak password</li></ul>&nbsp;<ul><li>Password-Authenticated Key Exchange (PAKE)</li></ul>This protocol uses password-authenticated key exchange (PAKE) for the PASE protocol:<ul><li>Computation of pA</li><li>Computation of pA</li><li>Computation of transcript TT</li><li>Computation of cA, cB and Ke</li></ul>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

Chapter 3 _ Cryptographic Primitives

Chapter 2 – Standard Matter Communication Architecture&nbsp;In the first lesson, we got a general understanding of the Matter communication standard. Now, in this article, we are going to talk about the architecture of this standard. First, we will have a general overview of this chapter, and then we will review the types of architecture, topology, identifiers and device setup. Stay with us&nbsp;Review of this chapterThe main goal of the Matter standard is to create a universal communication protocol based on IPv6 for all smart home devices. This standard defines the application layer protocol that is deployed on different devicesIn the figure below, the application layer and network stack are shown:&nbsp;<figure class="image image_resized" style="width:53.49%;"><img src="https://platform.iotsmile.com/assets/uploads/720d159c168e8605--8bbe5b47--1412ecd2--aac2cdea--0256fdcfe50085359aed10c72071849.png"><figcaption>Figure 1 - Application and network stack</figcaption></figure>&nbsp;Layered ArchitectureIn a layered architecture, different layers based on diverse responsibilities help to create appropriate levels of encapsulation among the protocol stack pieces.&nbsp;<figure class="image image_resized" style="width:36.22%;"><img src="https://platform.iotsmile.com/assets/uploads/72f98c2c85f89300--8eb3584e--1419e9d3--a9c7cce1--0652fbcae30783339ded16c1404223.png"><figcaption>Figure 2- Layered architecture and its role in encapsulation of the stack protocol</figcaption></figure>&nbsp;The application layer corresponds to the business logic of a device. For example, an application related to lighting might have logic to turn on/off a lamp and change its color. The data layer of the model is related to the data and supports the functionality of the application. The interaction model layer represents the set of interactions between a client and a server device. When an action is created using the interactive model, it is placed serially into a predefined binary packet to be encoded for network transmission.&nbsp;Network TopologyAny network that has an IPv6 address and supports several of its main standards is suitable for implementing the Matter standard. In this version of the Matter standard specifications (version 1.0), we will review three technologies: Ethernet, Wi-Fi and Thread:Because the Matter protocol considers networks as shared resources, it has no commitment to ownership or access to any of these networks. Therefore, it is possible to create multiple Matter networks on a set of covered IP networks. This standard may also operate in the absence of a globally routable IPv6 infrastructure. As a result, it enables operation in a network that is cut off from the global Internet or firewall. It also provides the possibility of deployment in situations where the Internet Service Provider (ISP) at the user's location does not support IPv6 or there are other restrictions.This protocol supports local connections that span one or more IPv6 subnets. Conventional networks that support Fabric may consist of a Wi-Fi/Ethernet subnet or one or more Low power and lossy Networks (LLN) subnets.&nbsp;&nbsp; &nbsp; &nbsp;1.Single network&nbsp;<figure class="image"><img src="https://platform.iotsmile.com/assets/uploads/a2610725f195c308--84b25e49--1417e6d9--a9c3c8ed--085cf8c0ea03853190e61eca9982746.png"><figcaption>Figure 3. Single Thread network</figcaption></figure>&nbsp;<figure class="image"><img src="https://platform.iotsmile.com/assets/uploads/bb76210dd07f9001--8eb4544d--1413e9d0--a9cec7e2--0457f3c3e905833f9be41dc71807872.png"><figcaption>Figure 4. Single Wi-Fi network</figcaption></figure>In single network topology, all Matter devices are connected to a logical network such as Thread/802.15.4, Wi-Fi network or Ethernet network. In the case of Wi-Fi/Ethernet, the network can actually consist of multiple Wi-Fi or Ethernet segments, provided that all segments are connected at the link layer.A node is a single instance of a Matter device in a Fabric that is operationally available on an IP network. Each node in the unified network topology can communicate with any other node in the fabric through a single network interface.&nbsp;&nbsp; &nbsp; &nbsp;2.Star network topology&nbsp;&nbsp;<figure class="image"><img src="https://platform.iotsmile.com/assets/uploads/a3a9435c99020b06--86bd545f--1418eddb--a9cec8e0--0257f5c8e208863a92ee19c65316134.png"><figcaption>Figure 5. Star network topology</figcaption></figure>&nbsp;A star network topology consists of several peripheral networks connected by a central hub network. While fringe networks are capable of supporting any type of network, a fringe network must always be directly connected to the hub network through one or more border routers.Architecturally, any number of peripheral networks, including multiple networks of the same type, can exist in a fabric. Nodes may have interfaces on any network (hub or peripheral) and communicate directly with other nodes in the same network. However, any communication that must cross a network boundary to reach its destination must flow through a boundary router.&nbsp;&nbsp; &nbsp; 3.IdentifiersIn the following, we will examine the types of identifiers available in this standard:&nbsp;&nbsp; &nbsp;4.Fabric References and Fabric Identifier&nbsp;A Fabric ID is a 64-bit number that uniquely identifies the Fabric within the scope of a particular root CA. In the data model, Fabric is known as a set of nodes that interact with each other by accessing data model elements.<ul><li style="text-align:justify;">Vendor Identifier (Vendor ID, VID)</li></ul>A Vendor Identifier (Vendor ID or VID) is a 16-bit number that uniquely identifies a particular product manufacturer, vendor, or group thereof. Each Vendor ID is statically allocated by the Connectivity Standards Alliance (CSA).<ul><li style="text-align:justify;">Product Identifier (Product ID, PID)</li></ul>A Product Identifier (Product ID or PID) is a 16-bit number that uniquely identifies a product of a vendor. The Product ID is assigned by the vendor and SHALL be unique for each product within a Vendor ID. Once a Product ID has been used, it SHALL NOT be reused by a different product type under the same Vendor ID. These Product IDs SHOULD NOT be specific to a unique physical device; rather they describe the product type, which might have many manufactured instances (e.g., multiple colors of the same product type).<ul><li style="text-align:justify;">Group Identifier (GID)</li></ul>A Group Identifier (Group ID or GID) is a 16-bit number that identifies a set of Nodes across a Fabricat the message layer. A Group ID can further be bound to one or more Endpoints within each Node in the group at the interaction layer.<ul><li style="text-align:justify;">Node Identifier</li></ul>A Node Identifier is a 64-bit number that uniquely identifies an individual Node or a group of Nodes on a Fabric. This identifier is classified into the following types:<ul><li style="text-align:justify;">Operational Node ID</li><li style="text-align:justify;">Group Node ID</li><li style="text-align:justify;">Temporary Local Node ID</li><li style="text-align:justify;">PAKE key identifiers</li><li style="text-align:justify;">CASE Authenticated Tag</li><li style="text-align:justify;">Unspecified Node ID</li></ul>&nbsp;<ul><li style="text-align:justify;">IPv6 Addressing</li></ul>The Matter protocol uses IPv6 addressing for its operational communications, and node and fabric identifiers are divided into different types of IPv6 addresses as follows:<ul><li style="text-align:justify;">IPv6 Unicast Address</li><li style="text-align:justify;">IPv6 Multicast Address</li><li style="text-align:justify;">IPv6 Multicast Port Number</li><li style="text-align:justify;">IPv4 Coexistence</li></ul>&nbsp;<ul><li style="text-align:justify;">Device identity&nbsp;</li></ul>Each Matter device contains a number of certificate chains. The Device Acknowledgment Certificate (DAC) actually proves the manufacturer's authenticity and the hardware and software certification status of the device. Each Matter device has an ONI (Operational Node ID) and a NOC (Node Operational Certificate) issued for the operational node ID. NOC enables a node to identify itself within a fabric through encryption.<ul><li style="text-align:justify;">Security</li></ul>The Matter communication standard uses modern security practices to protect the Fabric. Matter provides a comprehensive set of basic security principles, which are detailed in Chapter 3.&nbsp;<ul><li style="text-align:justify;">Device Commissioning</li></ul>Device commissioning, described in Chapter 5, is actually the process of connecting a device to a fabric. The device being commissioned is referred to as the Commissionee and the device administering&nbsp;commissioning is referred to as the Commissioner Setting up the device consists of several steps, which we briefly mention:<ul><li style="text-align:justify;">Device discovery</li></ul>In this step, the orderable devices are discovered on network interfaces such as Bluetooth Low Energy, Wi-Fi, or other connected IP networks.&nbsp;<ul><li style="text-align:justify;">Security setup with PASE</li></ul>Establish encryption keys between the Commissioner and Commissionee using PASE.&nbsp;All messages exchanged between the Commissioner and Commissionee are encrypted using&nbsp;these PASE-derived keys. The process also establishes an attestation challenge used during the&nbsp;device attestation procedure.<ul><li style="text-align:justify;">Device attestation verification</li></ul>Commissioner establishes&nbsp;the authenticity of the Commissionee as a certified device, notifying the user if the device is not&nbsp;certified.<ul><li style="text-align:justify;">Information configuration</li></ul>The Commissioner provides Commissionee with information such as regulatory&nbsp;domain, UTC time, Operational Certificate and network interfaces configuration.<ul><li style="text-align:justify;">Join network</li></ul>The Commissioner triggers the Commissionee to connect to the operationalnetwork unless the Commissionee is already on the operational network. The Node’s/Commissioner’s&nbsp;IPv6 address is then either used (if already known) or discovered (if not&nbsp;known) by the&nbsp;Commissioner or Administrator<ul><li style="text-align:justify;">Security setup with CASE</li></ul>Derive encryption keys used to establish secure communication between the Commissioneror Administrator and Node with CASE. All unicast messages between a commissioner or&nbsp;Administrator and a Node are encrypted using these CASE-derived keys.<ul><li style="text-align:justify;">Commissioning complete message exchange</li></ul>A message exchange encrypted using CASE-derived encryption keys on the operational&nbsp;network that indicates successful completion of commissioning process.&nbsp;<ul><li style="text-align:justify;">Sleepy End Device (SED)</li></ul>One of the goals of the Matter communication standard is to support low&nbsp;operate with limited power sources such as batteries or energy removal. The SED performance mode is defined to help increase and optimize battery life for such nodes and corresponds to Thread SED behavior. However, it may use other supported IP interfaces, including Wi-Fi. In a Thread network, the infrastructure device is a parent Thread router. For Wi-Fi, the access point supports the required infrastructure. Two intervals are defined: energy nodes that<ul><li style="text-align:justify;">Idle Mode</li></ul>Idle mode, or slow-polling, sets the maximum time a SED will sleep before polling. This parameter affects both the minimum power consumption and maximum latency. The SLEEPY_IDLE_INTERVAL parameter communicates the maximum sleep interval of a node in idle mode.<ul><li style="text-align:justify;">Active Mode</li></ul>Active mode sets the SED into a fast-polling interval for maximum responsiveness when theNode is engaged in ongoing communication, such as an active Exchange. The SLEEPY_ACTIVE_INTERVAL parameter communicates the maximum sleep interval of a node in active mode.<ul><li style="text-align:justify;">Data Model Root</li></ul>It has two endpoints:<ul><li style="text-align:justify;">Endpoint 0 (zero) SHALL be the root node endpoint.</li><li style="text-align:justify;">Endpoint 0 (zero) SHALL support the Root Node device type.</li></ul>Stack Limits&nbsp;In general, the stack has two types of limitations, namely System Model Limits and interactive model limitations.<ul><li style="text-align:justify;">System Model Limits</li></ul>It includes two types of limits: Access Control Limits and Group Limits, which will be explained in detail in the next lessons.<ul><li style="text-align:justify;">Interaction Model Limits</li></ul>This restriction includes three parts:&nbsp;<ul><li style="text-align:justify;">Read Interaction Limits</li><li style="text-align:justify;">Subscribe Interaction Limits</li><li style="text-align:justify;">Invoke Interaction Limits</li></ul>At the end of the second chapter of the comprehensive document of the Matter communication standard, a list of conditional items is mentioned, including IMP (Invoke Multiple Paths), EGA (Event List Global Attribute), Proxy Service and Time Synchronization.

Standard Matter Communication Architecture

Chapter 2 _ Standard Matter Communication Architecture

Introduction to the Matter communication standard

Chapter 1 _ Introduction to the Matter communication standard

Matter, the latest wireless communication standard&nbsp;Matter is an Internet Protocol (IP)-based communication standard for smart home technologies that helps create an open-source smart home; Where the products of different brands can communicate and share their data without any obstacles, and the problems related to the compatibility of products with each other do not exist anymore.The Connectivity Standards Committee (CSA), as a leader in the field of Internet of Things (IoT) technologies in the world, has taken a new step towards introducing this innovation by presenting a comprehensive technical specification document of the Matter standard. For those interested in the field of Internet of Things to get more familiar with the features of this standard, in this article, we will briefly review the different chapters of this document.&nbsp;The comprehensive technical specification document of the Matter standardThe comprehensive document of technical specifications of Matter is the most important and comprehensive document introducing this standard and consists of thirteen chapters. In order to have a general overview of the contents of this document, we invite you to read the rest of this article.At the beginning of this document, the Connection Standards Committee (CSA) has emphasized that the permission to reproduce, print and publish this document is granted only to the members of the Connection Standards Alliance, and any use from this document for commercial purposes, it is necessary to obtain a written consent from this committee.After that, by reviewing the titles of the list and the chapters of this document, it provides additional information for those interested in the field of technology and Internet of Things (IoT).In the first chapter, after giving a short introduction and introducing the Matter standard, things like the goals of this document, abbreviations and their definitions and the sources used in its writing are mentioned.Chapter 2 provides an overview of Matter's architecture, discussing in detail network topology, identifier types, IPv6 addressing, security, device setup, and system model constraints.The third chapter introduces the concepts of cryptography, algorithms and protocol construction.Check out Chapter 4 to learn more about secure channels. In this chapter, message types, protocols and methods of its exchange, IPv6 availability and network configuration requirements and security processing of incoming and outgoing messages are explained in detail.The purpose of the fifth chapter titled Setup is to define the Onboarding Payload requirements in order to obtain permission to install the device on the Matter network. This chapter also examines the display and encoding of the payload, which is manually placed as a QR Code and in the form of content in an NFC tag.In the sixth chapter, cryptographic procedures and credits related to establishing trust between entities are described. The device certification and measurement section provide mechanisms for administrators that enable them to verify the validity of a Node's certificate before sharing information.The seventh chapter of the comprehensive technical specification document of the Matter standard examines the data model, and it can also be called the meta model. This data model is finally implemented in the application layer of a communication stack. In fact, this chapter defines first-order elements for endpoints, clusters, and data types.In the eighth chapter and in continuation of what was mentioned in the previous chapter, the characteristics of the interactive model are described in detail and the interactions, transactions and actions between the nodes are also examined.The ninth chapter under the title of system model specifications has analyzed and investigated the relationships between endpoints and clusters.The coding specification of the interactive model is given in the tenth chapter. This specification describes in detail the interaction model (IM) encoding in the Matter TLV format.In the eleventh chapter, service and device management is reviewed; Where useful information is provided in relation to the necessary features and events in order to determine the basic information about the Nodes.The twelfth chapter examines the Multiple Fabric feature. This feature allows a Node to connect to multiple Fabrics that are managed independently. Using this feature, an administrator can allow another fabric to run that node in its fabric with user consent.In the thirteenth (last) chapter, the security requirements of the Matter standard are mentioned. These requirements are categorized by topic and typically address all devices and nodes. Among these, some requirements are specifically called for a certain group of implementations or roles.It should be noted that the comprehensive technical specification document of the Matter standard consists of seven appendices, where things such as encryption format, status report messages, object identifiers, etc. can be seen in these appendices.&nbsp;&nbsp;&nbsp;&nbsp;

Matter, the latest wireless communication standard

Introduction to the Matter Communication Standard

Introduction of the Matter communication standard

IoTSmile Academy

Categories

Recently-Updated

Chapter 4 - Part 6 Message counters

Chapter 4 - Part 5 Discover Gateway

Chapter 4 - Part 4 section operational discovery

Chapter 4 - Part 3 Review of TXT key functions

Chapter 4 - Part 2 Commissionable Node Discovery

Chapter 4 - Part 1 Messages and IPv6 reachability

Chapter 3 _ Cryptographic Primitives

Chapter 2 _ Standard Matter Communication Architecture

Chapter 1 _ Introduction to the Matter communication standard

Introduction to the Matter Communication Standard