61 Matter Fabric & Security
Matter’s fabric architecture enables multi-vendor interoperability by allowing a single device to belong to up to 5 independent administrative domains (fabrics), each with its own certificate chain and access controls. Security is built on PASE (passcode-based SPAKE2+ for commissioning) and CASE (certificate-based Sigma protocol for operation), with all traffic encrypted using AES-128-CCM and authorized through four privilege levels (View, Operate, Manage, Administer).
61.1 Matter Fabric Management and Security Architecture
By the end of this section, you will be able to:
- Differentiate between Matter fabrics and traditional single-admin architectures
- Trace the fabric certificate chain from Root CA through Intermediate CA to Node Operational Certificates
- Compare PASE (SPAKE2+) and CASE (Sigma protocol) session establishment mechanisms
- Configure Access Control Lists (ACLs) for appropriate privilege levels
- Design network topologies with redundant border routers for fault tolerance
- Diagnose common security and fabric-related commissioning failures
“Imagine your smart light bulb is a house with multiple locks,” said Max the Microcontroller. “Each smart home platform – Apple, Google, Amazon – gets its own key. That is what Matter calls a fabric! One device can belong to up to 5 different fabrics at the same time.”
Sammy the Sensor was impressed. “So my light bulb works with Siri AND Alexa AND Google at the same time?” Max nodded. “Each fabric has its own certificate chain – like a notarized ID card. When a new controller wants to join, it goes through a special handshake. First PASE – you type in the setup code from the box. Then CASE – the device and controller exchange certificates to prove they are who they claim to be.”
“And everything is encrypted!” added Lila the LED proudly. “AES-128-CCM encryption on every message. Even if someone intercepts the radio signal, they cannot read it without the encryption keys. Plus, there are four permission levels: View, Operate, Manage, and Administer – so a guest can turn on a light but cannot change the network settings.”
Bella the Battery summed it up. “Security with Matter is not optional – it is built in from the ground up. Every device, every message, every interaction is authenticated and encrypted.”
61.2 Prerequisites
Before diving into this chapter, you should be familiar with:
- Matter Protocol Stack and Data Model: Understanding nodes, endpoints, clusters
- Matter Interactions and Commissioning: How devices are commissioned
- Encryption Architecture: Cryptographic foundations
- Matter Fabric: A cryptographic domain in Matter where all devices share a root certificate authority, enabling secure multi-admin access and cross-ecosystem interoperability.
- NOC (Node Operational Certificate): An X.509 certificate issued to each Matter device during commissioning that identifies the device within a specific fabric.
- Root CA Certificate: The trust anchor for a Matter fabric; every NOC and ICAC is signed by this certificate, establishing the chain of trust.
- PASE (Passcode-Authenticated Session Establishment): A Matter protocol using SPAKE2+ for initial commissioning authentication using a device’s setup passcode.
- CASE (Certificate-Authenticated Session Establishment): A Matter protocol using NOC certificates for session establishment after commissioning, providing mutual device authentication.
- Multi-Admin Access: Matter’s capability allowing multiple controller applications (from different ecosystems) to simultaneously control the same device via separate fabric memberships.
- ACL (Access Control List): A Matter data model element on each device specifying which nodes have which permissions (administer, operate, view) for which clusters.
61.4 For Beginners: Understanding Fabrics
Think of a Matter fabric like a private club membership:
- The Club (Fabric) = An ecosystem like Apple Home or Google Home
- Membership Card (Certificate) = Proves you belong to the club
- Club Rules (ACL) = Who can do what in the club
- Multiple Memberships = Your device can join multiple clubs
When your smart light joins both Apple Home and Google Home: - It gets a separate membership card for each club - Each club can control the light independently - Neither club can see or interfere with the other’s control - If one club closes, the other still works
61.5 Fabric Architecture
61.5.1 What is a Fabric?
A Fabric is an administrative domain in Matter - a set of nodes that share: - Common Root Certificate Authority (CA) - Unique Fabric ID (64-bit) - Access Control Lists (ACLs) for authorization
Think of Fabrics as:
- Separate “organizations” that can control the same device
- Each ecosystem (Apple Home, Google Home) operates its own fabric
- A device can belong to multiple fabrics simultaneously
Let’s quantify the storage and cryptographic costs of multi-fabric support:
Certificate Storage (per fabric): \[ \begin{aligned} \text{Device certificate (NOC):} \quad & 512\text{ bytes (P-256 ECC, Subject, Issuer fields)} \\ \text{Fabric Root CA cert:} \quad & 512\text{ bytes (Root certificate chain)} \\ \text{Fabric metadata:} \quad & 128\text{ bytes (Fabric ID, ACL entries)} \\ \text{Total per fabric:} \quad & 512 + 512 + 128 = 1{,}152\text{ bytes} \\ \\ \text{5-fabric device storage:} \quad & 5 \times 1{,}152 = 5{,}760\text{ bytes (5.6 KB)} \\ \text{Plus session keys:} \quad & 5 \times 16\text{ bytes (AES-128 per fabric)} = 80\text{ bytes} \\ \text{Total credential storage:} \quad & 5{,}760 + 80 = 5{,}840\text{ bytes} \end{aligned} \]
CASE Session Establishment Cost (per fabric): \[ \begin{aligned} \text{Sigma handshake (3 flights):} \quad & 2 \times 256\text{ bytes (Sigma1, Sigma2)} + 192\text{ bytes (Sigma3)} = 704\text{ bytes} \\ \text{ECDH P-256 key gen:} \quad & t_{\text{keygen}} \approx 45\text{ ms (nRF52840 @ 64 MHz)} \\ \text{ECDSA sign operation:} \quad & t_{\text{sign}} \approx 38\text{ ms} \\ \text{Certificate verification:} \quad & t_{\text{verify}} \approx 42\text{ ms (chain validation)} \\ \text{Total CASE handshake time:} \quad & 45 + 38 + 42 = 125\text{ ms} \\ \\ \text{Energy cost (active @ 15mA):} \quad & E = 3\text{V} \times 15\text{mA} \times 125\text{ms} = 5.625\text{ mJ} \end{aligned} \]
ACL Storage (granular access control): \[ \begin{aligned} \text{ACL entry size:} \quad & 32\text{ bytes (Fabric ID, Cluster, Node ID, Privilege)} \\ \text{Typical entries per device:} \quad & 10\text{ entries (2 admins + 8 controllers)} \\ \text{Total ACL storage:} \quad & 10 \times 32 = 320\text{ bytes} \end{aligned} \]
Multi-Fabric Session Memory (simultaneous active sessions): \[ \begin{aligned} \text{Per-session state:} \quad & 256\text{ bytes (crypto context, IV, counters)} \\ \text{5 fabrics × 2 controllers each:} \quad & 10 \times 256 = 2{,}560\text{ bytes (2.5 KB RAM)} \end{aligned} \]
A typical Matter light bulb with 5-fabric support needs ~8.4 KB total (5.8 KB flash + 2.5 KB RAM), feasible on resource-constrained chips like ESP32-C3 (384 KB SRAM, 4 MB flash).
61.5.2 Multi-Admin Support
Key Multi-Admin Concepts:
| Concept | Description | Limit |
|---|---|---|
| Max Fabrics | Maximum simultaneous fabrics per device | 5 (typical) |
| Commissioning Window | Time window for adding to new fabric | 15 minutes |
| Administrator | Node that can modify device configuration | Per-fabric |
| ACL Entry | Permission grant for a subject | 4 per fabric |
61.5.3 Fabric Certificate Chain
Each fabric establishes identity through X.509 certificates:
Certificate Contents:
- Subject: Node ID + Fabric ID
- Issuer: Fabric Root CA or Intermediate CA
- Validity: Typically 1 year (renewable)
- Public Key: Device’s operational public key
- Extensions: Matter-specific attributes
61.6 Security Architecture
61.6.1 Session Establishment Protocols
Matter uses two session establishment protocols:
| Protocol | Full Name | Purpose | When Used |
|---|---|---|---|
| PASE | Passcode Authenticated Session Establishment | Initial secure session | Commissioning only |
| CASE | Certificate Authenticated Session Establishment | Operational sessions | Normal operation |
61.6.2 PASE: Commissioning Security
Purpose: Establish initial secure session using setup code from QR/NFC
PASE uses SPAKE2+ (Simple Password Authenticated Key Exchange):
PASE Security Properties:
- Zero-knowledge proof: Neither party learns the other’s passcode
- Forward secrecy: Compromised passcode doesn’t reveal past sessions
- Mutual authentication: Both parties prove knowledge of passcode
Setup Code Format:
- 11-digit numeric: “34970112332”
- Encodes: Discriminator (12-bit) + Passcode (27-bit)
- Source: QR code, NFC tag, or manual entry
61.6.3 CASE: Operational Security
Purpose: Establish secure sessions between fabric members using certificates
CASE uses a three-message Sigma protocol:
CASE Security Properties:
- Certificate-based identity: Verified by fabric Root CA
- Session resumption: Cache session keys for fast reconnection
- Perfect forward secrecy: Each session uses fresh ephemeral keys
61.6.4 Quick Check: Session Protocols
61.6.5 Message Encryption
All Matter messages after session establishment are encrypted:
| Security Feature | Algorithm | Key Size |
|---|---|---|
| Encryption | AES-CCM | 128-bit |
| Integrity | AES-CCM MAC | 128-bit tag |
| Key Derivation | HKDF-SHA256 | 256-bit |
| Signatures | ECDSA P-256 | 256-bit curve |
Message Security Layers:
┌─────────────────────────────────────┐
│ Encrypted Payload (AES-CCM) │
├─────────────────────────────────────┤
│ Message Authentication Code (MAC) │
├─────────────────────────────────────┤
│ Anti-replay Counter │
├─────────────────────────────────────┤
│ Session ID │
└─────────────────────────────────────┘61.6.6 Access Control Lists (ACLs)
ACLs define what operations each subject can perform:
| Privilege | Capabilities |
|---|---|
| View | Read attributes, subscribe to changes |
| Operate | View + invoke commands |
| Manage | Operate + write attributes |
| Administer | Manage + modify ACLs |
ACL Entry Structure:
{
"fabricIndex": 1,
"privilege": "Operate",
"authMode": "CASE",
"subjects": [NodeId(0x0001), NodeId(0x0002)],
"targets": [
{ "cluster": 0x0006, "endpoint": 1 } // On/Off on Endpoint 1
]
}61.7 Network Topology Patterns
61.7.1 Thread + Wi-Fi Hybrid
Most smart homes use a hybrid topology with Thread for low-power devices and Wi-Fi for high-bandwidth:
61.7.2 Border Router Redundancy
Multiple Border Routers provide fault tolerance:
| Scenario | 1 Border Router | 2+ Border Routers |
|---|---|---|
| BR failure | Thread mesh isolated | Seamless failover |
| Wi-Fi outage | Limited local control | Mesh continues locally |
| Range | Limited coverage | Extended coverage |
| Load | Single point of congestion | Load distributed |
Border Router Placement Guidelines:
- Place at “edges” of desired coverage area
- One BR per 20-30 Thread devices
- Mix ecosystems (HomePod + Nest Hub) for redundancy
- Consider power reliability (UPS for critical BRs)
61.8 Common Pitfalls
The Mistake: Developers repeatedly commission a Matter device to different test fabrics during development without properly removing old fabric entries. The device eventually reaches its maximum fabric capacity (typically 5 fabrics), and new commissioning attempts fail with “Fabric table full” or “NOC storage exhausted” errors.
Why It Happens: Each Matter fabric commissioning stores a Node Operational Certificate (NOC), fabric credentials, and ACL entries in persistent storage. The MaxFabrics capability is typically 5 for constrained devices. Unlike Wi-Fi credentials that overwrite, Matter fabrics accumulate.
The Fix: Properly remove fabrics before reaching the limit:
// Check current fabric count before commissioning
uint8_t fabricCount = cycleGetFabricCount();
uint8_t maxFabrics = cycleGetMaxFabrics(); // Typically 5
if (fabricCount >= maxFabrics) {
// Remove unused fabrics via OperationalCredentials cluster
// Command: RemoveFabric (0x0A) with FabricIndex
cycleOperationalCredentialsRemoveFabric(fabricIndex);
}
// For complete wipe during development:
cycleFactoryResetCredentials(); // Clears NOCs + fabrics + ACLsIn production apps, implement fabric management UI showing current fabric count.
The Mistake: After rotating a device’s Node Operational Certificate (NOC), existing CASE sessions continue using cached session keys. Controllers then fail to communicate with the device, showing “Session expired” or “CASE handshake failed” errors.
Why It Happens: CASE supports session resumption to avoid expensive full handshakes. Session resumption tokens are tied to the specific NOC public key. When the NOC is rotated, the device’s identity changes but controllers may still attempt resumption with stale session data.
The Fix: Implement proper session invalidation during NOC rotation:
// On device side: After NOC update, clear all CASE sessions
void OnNOCUpdated() {
// Invalidate all active CASE sessions
CASESessionManager::InvalidateAllSessions();
// Clear session resumption cache
SessionResumptionStorage::ClearAll();
// Force controllers to perform fresh CASE handshake
}
// On controller side: Handle NOC rotation gracefully
void OnDeviceCertificateChanged(NodeId node) {
// Remove cached session for this node
SessionManager::EvictSession(node);
// Next interaction will trigger fresh CASE handshake
}61.9 Visual Reference Gallery
Explore alternative visual representations of Matter fabric and security concepts.
Matter’s fabric architecture enables multi-admin control where devices can belong to multiple ecosystems with independent automation rules.
61.10 Knowledge Check
61.11 Quick Assessment
61.11.1 Knowledge Check: Matter Fabric Architecture
61.11.2 Knowledge Check: PASE vs CASE
61.11.3 Knowledge Check: Matter Access Control
Scenario: A Matter smart light bulb is commissioned into 3 fabrics (Apple Home, Google Home, Amazon Alexa). Each ecosystem polls the device state every 30 seconds. Calculate the battery impact if the bulb were battery-powered.
Step 1: Calculate single-fabric traffic
Controller polling (Apple Home):
Read OnOff cluster (attribute 0x0000) every 30 seconds
Frame structure:
- CASE session (already established, session resumption)
- Read attribute request: ~20 bytes
- Read attribute response: ~15 bytes
- Total: 35 bytes per poll
CASE session maintenance:
- Session resumption: ~50 bytes every 10 minutes
- Full CASE handshake: ~300 bytes every 24 hours (session expiry)Step 2: Calculate three-fabric traffic
3 ecosystems × 120 polls/hour × 35 bytes = 12,600 bytes/hour
Session maintenance (3 fabrics):
- 3 × 6 session resumptions/hour × 50 bytes = 900 bytes/hour
- 3 × 1 full CASE/day × 300 bytes = 900 bytes/day = 37.5 bytes/hour
Total traffic: 12,600 + 900 + 37.5 = 13,537.5 bytes/hourStep 3: Calculate airtime and energy
Thread (802.15.4 at 250 kbps):
Frame overhead: ~25 bytes per message
Total per poll: 35 + 25 = 60 bytes
TX time: (60 × 8) / 250,000 = 1.92 ms
360 polls/hour (3 fabrics × 120):
Airtime: 360 × 1.92 ms = 691 ms/hour = 19.2% duty cycle
Radio current (typical Thread radio):
TX: 22 mA
RX (listening): 18 mA
Deep sleep: 1 µA
Energy consumption (3 fabrics):
TX: 691 ms/hour × 22 mA = 15.2 mAh/hour
RX (must listen for incoming): 100 ms/poll × 18 mA = 648 mAh/hour
Total: 663 mAh/hour = 15.9 Ah/day
CR2032 battery: 220 mAh
Battery life: 220 / 663 = 0.33 hours = 20 minutes (FAILS)Step 4: Comparison to single-fabric
Single fabric (Apple Home only):
120 polls/hour × 1.92 ms = 230 ms/hour TX
Energy: 5.1 mAh/hour = 122 mAh/day
Battery life: 220 / 5.1 = 43 hours = 1.8 days (still impractical)Result: Multi-fabric operation increases traffic 3×, reducing battery life from 1.8 days (single fabric) to 20 minutes (three fabrics). This is why Matter light bulbs are mains-powered — battery operation is infeasible with frequent polling by multiple ecosystems.
Battery-powered Matter devices (e.g., door sensors):
- Use sleepy end device mode (RFD in Thread)
- Only wake on events (door open/close), not continuous polling
- Fabrics subscribe to attribute reports (push model) instead of polling
- Battery life: 1-2 years on CR2032 with infrequent events
| Application | PASE Passcode Strength | CASE Certificate Validity | ACL Privilege Levels Used | Reasoning |
|---|---|---|---|---|
| Smart home (consumer) | 11-digit numeric (setup code from QR) | 1 year (renewable) | View, Operate, Manage | Standard commissioning; yearly cert rotation acceptable; users need Manage for settings |
| Smart building (commercial) | 11-digit + NFC tag | 90 days | View, Operate, Administer | Shorter cert validity for compliance; Administer for facility managers only |
| Healthcare (patient monitoring) | 11-digit + PIN verification | 30 days | View only (most devices) | HIPAA compliance; frequent rotation; minimal privileges |
| Industrial control | NFC tag only (no manual entry) | 7 days | Operate (devices), Administer (supervisors) | Prevent social engineering; very short cert validity; strict ACL separation |
ACL design best practices:
For a smart light bulb with 2 fabrics (Apple Home + Google Home):
// Fabric 1 (Apple Home) ACL:
[
{
"privilege": "Administer",
"subjects": [0x1001], // iPhone
"targets": null // All endpoints
},
{
"privilege": "Operate",
"subjects": [0x1002, 0x1003], // HomePod, Apple Watch
"targets": [{"cluster": 0x0006, "endpoint": 1}] // OnOff cluster only
}
]
// Fabric 2 (Google Home) ACL:
[
{
"privilege": "Administer",
"subjects": [0x2001], // Android Phone
"targets": null
},
{
"privilege": "Operate",
"subjects": [0x2002], // Nest Hub
"targets": [{"cluster": 0x0006, "endpoint": 1}]
}
]Privilege escalation protection:
- Voice assistants (HomePod, Nest Hub): Operate only (can turn on/off but cannot change network settings)
- Primary controllers (phones): Administer (can modify ACLs and provision new controllers)
- Guest controllers: View or Operate (read state or control but cannot add new devices)
The Error: A product engineer commissions a Matter device into 5 different test fabrics during development (Apple Home test, Google Home test, Amazon test, internal CI fabric, personal fabric). The device reaches MaxFabrics=5 capacity. During final QA testing, the device rejects commissioning into the production fabric with “Fabric table full” error.
Why this happens:
Matter fabric storage (typical constrained device):
MaxFabrics capability: 5
Each fabric stores:
- Node Operational Certificate (NOC): ~200 bytes
- Root CA certificate: ~300 bytes
- Fabric credentials: ~50 bytes
- ACL entries (4 per fabric): ~100 bytes
─────────────────────────────────────────────
Total per fabric: ~650 bytes
5 fabrics: 3,250 bytes persistent storage (non-volatile)
Test fabrics accumulate (not auto-removed):
Fabric 1: Apple Home test (week 1)
Fabric 2: Google Home test (week 2)
Fabric 3: Amazon Alexa test (week 3)
Fabric 4: Internal CI fabric (week 4)
Fabric 5: Engineer's personal network (week 5)
Attempt to commission into production fabric (week 6):
ERROR: NoFabricCapacity (fabric table full)How to prevent:
// Production firmware: Check fabric count during commissioning
void onCommissioningStart() {
uint8_t fabricCount = getFabricCount();
uint8_t maxFabrics = getMaxFabrics(); // Typically 5
if (fabricCount >= maxFabrics - 1) {
// Warn: One fabric slot remaining
logWarning("Fabric table nearly full: %d/%d", fabricCount, maxFabrics);
}
if (fabricCount >= maxFabrics) {
// Reject commissioning OR provide UI to remove unused fabrics
logError("Fabric table full. Remove unused fabric first.");
return CHIP_ERROR_NO_MEMORY;
}
}
// Development practice: Clear test fabrics after each test
void tearDownTest() {
// Remove all fabrics except default (factory reset credentials)
for (uint8_t i = 1; i <= getFabricCount(); i++) {
removeFabric(i);
}
// Or full factory reset:
// factoryResetCredentials();
}QA process:
- Before shipping: Factory reset device to clear all test fabrics
- Automated test: CI pipeline calls
factoryResetCredentials()between test runs - Production firmware: Implement fabric count warning at 80% capacity (4/5 fabrics)
- User-facing app: Show fabric list with “Remove” button (implement OperationalCredentials::RemoveFabric)
Recovery for stuck devices:
# Via CHIP Tool (Matter CLI):
chip-tool operationalcredentials remove-fabric 1 <node-id> <endpoint>
chip-tool operationalcredentials remove-fabric 2 <node-id> <endpoint>
# ... repeat for each test fabric
# Or nuclear option:
chip-tool generalcommissioning factory-reset <node-id> <endpoint>Lesson: Fabric storage is finite (typically 5 on constrained devices). Test automation MUST include fabric cleanup, and production firmware should warn users when approaching capacity.
61.12 Key Takeaways
61.13 Summary
Fabrics are administrative domains with shared Root CA, enabling multi-ecosystem control
Multi-admin allows one device to belong to up to 5 fabrics (typically) with independent certificates and ACLs
PASE (passcode-based) secures initial commissioning; CASE (certificate-based) secures ongoing operation
All Matter traffic is encrypted with AES-128-CCM after session establishment
ACL privilege levels: View < Operate < Manage < Administer
Multiple Border Routers provide fault tolerance and extended coverage for Thread mesh
Fabric certificate chain: Root CA -> Intermediate CA (optional) -> Node Operational Certificate
61.14 Practical Security Comparison: Matter vs Pre-Matter Smart Home Protocols
Understanding Matter’s security improvement requires comparing it to what came before:
| Security Feature | Zigbee 3.0 | Z-Wave S2 | Wi-Fi (WPA3) | Matter |
|---|---|---|---|---|
| Default encryption | AES-128-CCM | AES-128-CCM | AES-256-CCMP | AES-128-CCM |
| Key exchange | Pre-shared install code | ECDH + DSA | SAE (Dragonfly) | SPAKE2+ (PASE) + Sigma (CASE) |
| Device authentication | Install code (optional) | DSK (required) | Password | Certificate-based (NOC) |
| Certificate infrastructure | None | None | None (PSK-based) | Full PKI with DAC, PAI, PAA |
| Multi-admin security | Single trust center key | Single network key | Single network | Independent per-fabric keys |
| Key rotation | Manual (rarely done) | Manual | Via re-authentication | Fresh keys per CASE session (ephemeral ECDH) |
| Replay protection | Frame counter | Frame counter | Sequence number | Message counter + session ID |
| OTA update verification | Optional (CRC) | Required (signing) | N/A (app-level) | Required (signed + rollback protection) |
Why certificates matter: In Zigbee and Z-Wave, a compromised network key exposes all devices on the network. In Matter, each fabric has independent cryptographic credentials. Compromising Apple Home’s fabric credentials does not affect Google Home’s fabric on the same device – the attacker would need to separately compromise each ecosystem’s certificate chain.
The PASE bootstrapping problem: The setup code (printed on the QR code) is an 11-digit numeric value encoding a 27-bit passcode and 12-bit discriminator. SPAKE2+ prevents offline brute-force attacks on this passcode, but physical access to the QR code grants initial pairing capability. In shared environments (hotels, offices), cover or remove QR codes after commissioning to prevent unauthorized pairing.
61.15 What’s Next
| Chapter | Focus |
|---|---|
| Matter Device Types and Clusters | Explore the complete cluster library and device type definitions |
| Matter Implementation | SDKs, certification, and building Matter products |
| Thread Security and Matter | Thread-level security mechanisms complementing Matter’s fabric security |
| Thread Fundamentals and Roles | Thread as Matter’s primary mesh transport layer |
| Encryption Architecture | Deeper dive into AES-CCM, ECDSA, and HKDF foundations |