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 Freigeben 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 zuständigen Stelle auf einem Knoten festgelegt, in der Regel auf einem Gerät mit einer Benutzeroberfläche wie einem Smartphone, Hub oder Computer, nachdem sie von einem Administrative Domain Manager (ADM) empfangen wurde. Dies ist häufig ein System, 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.
- Beim NOCSR-Prozess werden Eingaben aus dem Attestation Procedure verwendet, die CSRSR-Informationen werden signiert und so wird die Anfrage an die Zertifizierungsstelle validiert, eine vertrauenswürdige NOC zu generieren.
Das Attestierungsverfahren ist ein Verfahren, mit dem der Datenschutzbeauftragte bestätigt, dass:
- Das Gerät wurde gemäß Matter zertifiziert.
- Das Gerät ist tatsächlich das, was es vorgibt zu sein: Es weist kryptografisch seinen Anbieter, seine Produkt-ID und andere Informationen zur Herstellung nach.
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 verschlüsselte 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.