Nachdem wir einige wichtige Konzepte eines Knotens kennengelernt haben, sehen wir uns an, was es Geräten ermöglicht, miteinander zu kommunizieren.
Die Matter-Spezifikation verwendet ausgefeilte Methoden zum Verschlüsseln und Entschlüsseln von Informationen sowie sichere Mechanismen zur Bestätigung der Identität eines Knotens und zum Teilen kryptografischer Anmeldedaten.
Wenn mehrere Geräte in einem Netzwerk dieselbe Sicherheitsdomain verwenden und somit eine sichere Kommunikation zwischen Knoten möglich ist, wird dies als Fabric bezeichnet. Fabrics verwenden dasselbe Top-Level-Zertifikat (Root of Trust) der Zertifizierungsstelle (CA) und im Kontext der Zertifizierungsstelle eine eindeutige 64‑Bit-Kennung namens Fabric ID.
Die Inbetriebnahme besteht also darin, den Fabric-Anmeldedaten einen neuen Knoten zuzuweisen, damit er mit anderen Knoten in derselben Fabric kommunizieren kann.
Betriebsanmeldedaten
Die Root of Trust wird von der Zertifizierungsstelle auf einem Knoten festgelegt, der in der Regel ein Gerät mit einer Benutzeroberfläche ist, z. B. ein Smartphone, Hub oder Computer. Sie wird von einem Administrative Domain Manager (ADM) empfangen, der oft ein System ist, das als Trusted Root Certificate Authority (CA) fungiert.
Der Beauftragte hat Zugriff auf die Zertifizierungsstelle. Daher fordert er die Betriebsberechtigungen für den Knoten im Namen des in Betrieb genommenen Knotens oder Auftragnehmers von der Zertifizierungsstelle an. Die Anmeldedaten bestehen aus zwei Teilen:
Die Node Operational Identifier (oder Operational Node ID) ist eine 64‑Bit-Zahl, die jeden Knoten in der Fabric eindeutig identifiziert.
Das Node Operational Certificate (NOC) ist die Gruppe von Anmeldedaten, mit denen Knoten innerhalb einer Fabric kommunizieren und sich identifizieren. Sie werden vom Prozess Node Operational Certificate Signing Request (NOCSR) generiert.
NOCSR ist ein Verfahren, das auf dem Knoten ausgeführt wird, der in Betrieb genommen wird. Es bindet mehrere kryptografische Elemente und sendet sie dann an den Beauftragten, der vom CA-System das entsprechende NOC anfordert. Abbildung 1 zeigt dieses Abhängigkeitsbaum und die Reihenfolge, in der einige Vorgänge ausgeführt werden.
Für die SDK-Entwicklung ist es zwar wichtig, die einzelnen kryptografischen Elemente zu verstehen, aber die Rolle und Auswirkungen dieser Elemente werden in diesem Artikel nicht vollständig analysiert. Wichtig ist Folgendes:
- NOCs werden vom CA-System in realen Produktionsumgebungen ausgestellt.
- NOCs sind kryptografisch an das eindeutige Knoten-Betriebsschlüsselpaar (NOKP) gebunden.
- Die NOKP wird vom Knoten generiert, der während der Inbetriebnahme in Betrieb genommen wird.
- Die an das System gesendeten NOCSR-Informationen enthalten den öffentlichen Betriebsschlüssel des Knotens. Der private Betriebsschlüssel des Knotens wird jedoch nie an den Bevollmächtigten oder die Zertifizierungsstelle gesendet.
- Der NOCSR-Prozess verwendet Eingaben aus dem Attestation Procedure, signiert die CSRSR-Informationen und validiert so die Anfrage an die Zertifizierungsstelle, eine vertrauenswürdige NOC zu generieren.
Das Attestierungsverfahren ist ein Verfahren, mit dem die Kommission bestätigt, dass:
- Das Gerät wurde gemäß Matter zertifiziert.
- Das Gerät ist tatsächlich das, was es vorgibt zu sein: Es bestätigt kryptografisch seinen Anbieter, seine Produkt-ID und andere Informationen zur Herstellung.
Multi-Admin
Knoten können auch in mehreren Fabrics in Betrieb genommen werden. Diese Property wird oft als Mehrfachverwaltung bezeichnet. Angenommen, ein Gerät ist sowohl für die Fabric des Herstellers als auch für die Fabric eines Cloud-Systems in Auftrag gegeben. Jede Fabric verarbeitet dabei eine andere Gruppe verschlüsselter Kommunikation und arbeitet unabhängig.
Da mehrere Fabrics nebeneinander existieren können, kann ein Gerät mehrere Node-Betriebsanmeldedaten haben. Das Datenmodell des Knotens wird jedoch gemeinsam verwendet: Die Clusterattribute, -ereignisse und -aktionen sind in allen Fabrics identisch. Auch wenn Thread- und/oder WLAN-Anmeldedaten während der Inbetriebnahme festgelegt werden, sind sie Teil des Netzwerk-Betriebsclusters, werden zwischen allen Fabrics freigegeben und sind Teil der DM des Knotens, nicht der Fabric-Anmeldedaten.