Der Stoff

Nachdem wir nun einige Schlüsselkonzepte von Knoten verstanden haben, analysieren wir, was Geräte die Kommunikation miteinander ermöglicht.

Die Spezifikation Matter verwendet ausgefeilte Methoden zum Verschlüsseln und Entschlüsseln von Informationen sowie sichere Mechanismen zur Sicherung der Identität eines Knotens und zur gemeinsamen Nutzung 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 Top-Level-Zertifikat der Zertifizierungsstelle (CA) (Root of Trust) und im Kontext der Zertifizierungsstelle eine eindeutige 64-Bit-Kennung mit dem Namen Fabric-ID.

Bei der Inbetriebnahme werden die Fabric-Anmeldedaten einem neuen Knoten zugewiesen, damit er mit anderen Knoten in derselben Fabric kommunizieren kann.

Operative Anmeldedaten

Die Vertrauensbasis wird auf einem Knoten festgelegt, der vom Commissioner in Betrieb genommen wird. Dies ist in der Regel ein Gerät mit einer Art GUI, z. B. einem Smartphone, Hub oder Computer, nachdem es von einem Administrative Domain Manager (ADM) empfangen wurde. Dies ist oft ein System, das als vertrauenswürdige Root-Zertifizierungsstelle (Trusted Root Certificate Authority, CA) fungiert.

Der Commissioner hat Zugriff auf die Zertifizierungsstelle. Daher fordert er die Betriebsdaten des Knotens von der Zertifizierungsstelle im Namen des in Auftrag gegebenen Knotens oder Kommissionses an. Die Anmeldedaten bestehen aus zwei Teilen:

Die Betriebsknoten-ID (oder Betriebsknoten-ID) ist eine 64-Bit-Zahl, die jeden Knoten in der Fabric eindeutig identifiziert.

Das Node Operational Certificate (NOC) besteht aus den Anmeldedaten, mit denen Knoten kommunizieren und sich in einer Fabric identifizieren. Sie werden durch den Prozess Node Operational Certificate Signing Request (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 entsprechende NOC beim CA-System anfordert. Abbildung 1 zeigt diese Abhängigkeitsstruktur und die Reihenfolge, in der einige Vorgänge stattfinden.

Abhängigkeiten der NOC-Generierung
Abbildung 1: Abhängigkeiten der NOC-Generierung

Zwar ist das Verständnis jedes kryptografischen Elements wichtig für die SDK-Entwicklung, es liegt jedoch außerhalb des Kompetenzbereichs von Primer, ihre Rolle und Auswirkungen vollständig zu analysieren. Beachten Sie Folgendes:

  • NOCs werden vom kalifornischen System auf realen Produktionsstoffen ausgegeben.
  • NOCs sind kryptografisch an das eindeutige operative Schlüsselpaar des Knotens (NOKP) gebunden.
  • NOKP wird von dem Knoten generiert, der während des Inbetriebnahmevorgangs in Betrieb genommen wird.
  • Zu den an das System gesendeten NOCSR-Informationen gehört der öffentliche operative Schlüssel des Knotens. Der private operative Schlüssel des Knotens wird jedoch niemals an den Commissioner oder die Zertifizierungsstelle gesendet.
  • Der NOCSR-Prozess verwendet Eingaben aus dem Zertifizierungsverfahren, um die CSRSR-Informationen zu signieren und so die Anfrage für die Zertifizierungsstelle zu validieren, um ein vertrauenswürdiges NOC zu generieren.

Mit dem Bescheinigungsverfahren bestätigt der Kommissar Folgendes:

  • Das Gerät hat die Zertifizierung Matter durchlaufen.
  • Das Gerät ist tatsächlich das, was es vorgibt: Es bestätigt Anbieter, Produkt-ID und andere Herstellungsinformationen kryptografisch.

Mehrere Administratoren

Knoten können auch auf mehr als einer Fabric in Auftrag gegeben werden. Diese Eigenschaft wird oft als Multi-Admin bezeichnet. Beispielsweise kann ein Gerät sowohl für die Fabric des Herstellers als auch für die Fabric eines Cloud-Ökosystems in Auftrag gegeben werden, wobei jede Fabric einen anderen Satz verschlüsselter Kommunikationen verarbeitet und unabhängig arbeitet.

Da mehrere Fabrics nebeneinander existieren können, kann ein Gerät mehrere Sätze von operativen Knoten-Anmeldedaten haben. Das Datenmodell des Knotens wird jedoch gemeinsam genutzt: Die Clusterattribute, Ereignisse und Aktionen sind in Fabrics gemeinsam. Obwohl Thread- und/oder WLAN-Anmeldedaten während der Inbetriebnahme festgelegt werden, sind sie Teil des operativen Netzwerkclusters, der von allen Fabrics und einem Teil des DM des Knotens gemeinsam genutzt wird, nicht den Fabric-Anmeldedaten.