The Fabric

Stay organized with collections Save and categorize content based on your preferences.

Now that we've understood some key concepts of a Node, we'll analyze what enables Devices to communicate with one another.

The Matter spec uses sophisticated methods for encrypting and decrypting information, as well as safe mechanisms for assuring a Node's identity and sharing cryptographic credentials.

Whenever a set of Devices in a network shares the same security domain, and thus allows secure communication between Nodes, this set is called a Fabric. Fabrics share the same Certificate Authority (CA) top-level certificate (Root of Trust) and within the context of the CA, a unique 64-bit identifier named Fabric ID.

Thus the commissioning process is the assignment of the Fabric credentials to a new Node so it may communicate with other Nodes in the same Fabric.

Operational credentials

The Root of Trust is set on a Node under commissioning by the Commissioner, typically a device with some type of GUI, such as a smartphone, hub or computer, after receiving it from an Administrative Domain Manager (ADM), which will often be an ecosystem that acts as a Trusted Root Certificate Authority (CA).

The Commissioner has access to the CA. Thus it requests the Node Operational Credentials from the CA on behalf of the node being commissioned or Commissionee. The credentials are made of two parts:

Node Operational Identifier (or Operational Node ID) is a 64-bit number that uniquely identifies every Node in the Fabric.

Node Operational Certificate (NOC) is the set of credentials that Nodes use to communicate and identify themselves within a Fabric. They are generated by the Node Operational Certificate Signing Request (NOCSR) process.

NOCSR is a procedure that runs on Node being commissioned. It binds several cryptographical elements, then sends them to the Commissioner, who requests the CA ecosystem for its corresponding NOC. Figure 1 depicts this dependency tree and the order by which some operations occur.

NOC generation dependencies
Figure 1: NOC generation dependencies

While understanding each cryptographic element is important for SDK development, it is outside of primer's scope to fully analyze their role and implications. What's important to note is that:

  • NOCs are issued by the CA ecosystem on real-world production fabrics.
  • NOCs are cryptographically bound to the unique Node Operational Key Pair (NOKP).
  • NOKP is generated by the node being commissioned during the commissioning process.
  • The NOCSR information sent to the ecosystem includes the Node Operational Public Key, but the Node Operational Private Key is never sent to the Commissioner or to the CA.
  • The NOCSR process uses inputs from the Attestation Procedure, signing the CSRSR information, and thus validating the request for the CA to generate a trusted NOC.

The Attestation procedure is a process used by the Commissioner to certify that:

  • The Device has gone through Matter certification.
  • The Device is indeed is what it claims to be: it cryptographically proves its Vendor, Product ID and other manufacturing information.

Multi-Admin

Nodes may also be commissioned on more than one Fabric. This property is often referred to as multi-admin. For instance, we may have a Device commissioned to both the manufacturer's Fabric and a cloud ecosystem's Fabric, with each Fabric handling a different set of encrypted communications and operating independently.

As several Fabrics may coexist, a Device might have several sets of Node operational credentials. However, the Node's Data Model is shared: the Cluster Attributes, Events, and Actions are common between Fabrics. Thus, although Thread and/or Wi-Fi credentials are set during the commissioning process, they are part of the Networking Operational Cluster, being shared between all the Fabrics and part of the node's DM, not the Fabric credentials.