Nachdem Sie nun einige Schlüsselkonzepte eines Knotens verstanden haben, analysieren wir, was Geräte ermöglicht, miteinander zu kommunizieren.
Die Spezifikation Matter verwendet ausgefeilte Methoden zum Verschlüsseln und Entschlüsseln sowie sichere Mechanismen zum Sicherstellen der Identität eines Knotens und zum Teilen kryptografischer Anmeldedaten.
Wenn eine Gruppe von Geräten in einem Netzwerk dieselbe Sicherheitsdomain verwendet und somit eine sichere Kommunikation zwischen Knoten ermöglicht, wird diese Gruppe als Fabric bezeichnet. Fabrics verwenden dasselbe übergeordnete Zertifikat der Zertifizierungsstelle (CA) (Root of Trust) und im Kontext der Zertifizierungsstelle eine eindeutige 64-Bit-Kennung namens Fabric ID.
Der Inbetriebnahmeprozess ist also die Zuweisung der Fabric-Anmeldedaten zu einem neuen Knoten, damit dieser mit anderen Knoten in derselben Fabric kommunizieren kann.
Operative Referenzen
Der Root of Trust wird auf einem Knoten festgelegt, der vom Commissioner in Betrieb genommen wird. In der Regel handelt es sich dabei um ein Gerät mit einer GUI (z. B. einem Smartphone, Hub oder Computer), nachdem es von einem Administrative Domain Manager (ADM) empfangen wurde. Dabei handelt es sich häufig um ein System, das als Trusted Root Certificate Authority (CA) fungiert.
Der Beauftragte hat Zugriff auf die Zertifizierungsstelle. Daher fordert er die Betriebsanmeldedaten von der Zertifizierungsstelle im Namen des in Auftrag gegebenen Knotens oder Kommissionsmitglieds an. Die Anmeldedaten bestehen aus zwei Teilen:
Die Knotenbetriebs-ID (oder Betriebsknoten-ID) ist eine 64-Bit-Nummer, die jeden Knoten in der Fabric eindeutig identifiziert.
Das Node Operational Certificate (NOC) ist der Satz von Anmeldedaten, mit denen Knoten in einer Fabric kommunizieren und sich identifizieren. Sie werden durch die Anfrage zur Signierung des Knotenbetriebszertifikats (NOCSR) generiert.
NOCSR ist ein Verfahren, das auf dem in Betrieb genommenen Knoten ausgeführt wird. Es bindet mehrere kryptografische Elemente und sendet sie dann an den Kommissar, der das CA-System für das entsprechende NOC anfordert. Abbildung 1 zeigt diesen Abhängigkeitsbaum und die Reihenfolge, in der einige Vorgänge ausgeführt werden.
Auch wenn es für die SDK-Entwicklung wichtig ist, jedes kryptografische Element zu verstehen, liegt es außerhalb des Umfangs, dessen Rolle und Auswirkungen vollständig analysiert werden können. Beachten Sie Folgendes:
- NOCs werden vom CA-Ökosystem für echte Produktionsmaterialien ausgegeben.
- NOCs sind kryptografisch an das eindeutige Node Operational Key Pair (NOKP) gebunden.
- NOKP wird von dem Knoten generiert, der während der Inbetriebnahme in Betrieb genommen wird.
- Die an die Umgebung gesendeten NOCSR-Informationen umfassen den öffentlichen Knotenbetriebsschlüssel, der private Knotenbetriebsschlüssel wird jedoch nie an den Commissioner oder die Zertifizierungsstelle gesendet.
- Der NOCSR-Prozess verwendet Eingaben aus dem Bestätigungsverfahren, signiert die CSRSR-Informationen und validiert damit die Anfrage an die Zertifizierungsstelle, um ein vertrauenswürdiges NOC zu generieren.
Das Bestätigungsverfahren ist ein Verfahren, mit dem der Auftraggeber Folgendes bestätigt:
- Das Gerät hat die Matter-Zertifizierung erhalten.
- Das Gerät ist in der Tat das, was es verspricht: es verifiziert seine Anbieter-ID, Produkt-ID und andere Fertigungsinformationen kryptografisch.
Mehrere Administratoren
Knoten können auch auf mehr als einer Fabric in Auftrag gegeben werden. Diese Property wird oft als „Multi-Admin“ bezeichnet. Beispielsweise können wir ein Gerät sowohl für die Fabric des Herstellers als auch für die Fabric eines Cloud-Systems in Auftrag geben lassen, wobei jede Fabric einen anderen Satz verschlüsselter Kommunikationen verarbeitet und unabhängig arbeitet.
Da mehrere Fabrics gleichzeitig vorhanden sein können, kann ein Gerät mehrere Sätze von Anmeldedaten für den Knotenbetrieb haben. Das Datenmodell des Knotens wird jedoch gemeinsam genutzt: Die Clusterattribute, Ereignisse und Aktionen sind für alle Fabrics gemeinsam. Obwohl Thread- und/oder WLAN-Anmeldedaten während der Inbetriebnahme festgelegt werden, sind sie Teil des Betriebsclusters für Netzwerke und werden von allen Fabrics und einem Teil der DM des Knotens gemeinsam genutzt, nicht die Fabric-Anmeldedaten.