Nachdem wir nun einige Schlüsselkonzepte eines Knotens kennengelernt haben, analysieren wir, was die Kommunikation zwischen Geräten ermöglicht.
Die Matter Spezifikation verwendet ausgefeilte Methoden zum Verschlüsseln und Entschlüsseln von Informationen sowie sichere Mechanismen, um die Identität eines Knotens zu bestätigen und kryptografische Anmeldedaten freizugeben.
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 Zertifikat der Zertifizierungsstelle (Certificate Authority, CA) auf oberster Ebene (Root of Trust) und im Kontext der CA eine eindeutige 64-Bit-Kennung namens Fabric-ID.
Beim Inbetriebnahmeprozess werden die Fabric-Anmeldedaten einem neuen Knoten zugewiesen, damit dieser mit anderen Knoten in derselben Fabric kommunizieren kann.
Betriebliche Anmeldedaten
Der Root of Trust wird auf einem Knoten bei der Inbetriebnahme vom Commissioner festgelegt. Das ist in der Regel ein Gerät mit einer grafischen Benutzeroberfläche, z. B. ein Smartphone, Hub oder Computer. Der Commissioner erhält den Root of Trust von einem Administrative Domain Manager (ADM), der oft ein Ökosystem ist, das als Trusted Root-Zertifizierungsstelle (CA) fungiert.
Der Commissioner hat Zugriff auf die CA. Er fordert daher die betrieblichen Anmeldedaten des Knotens im Namen des in Betrieb zu nehmenden Knotens oder Commissionee von der CA an. Die Anmeldedaten bestehen aus zwei Teilen:
Die betriebliche Kennung des Knotens (oder betriebliche Knoten-ID) ist eine 64-Bit-Zahl, die jeden Knoten in der Fabric eindeutig identifiziert.
Das betriebliche Zertifikat des Knotens (Node Operational Certificate, NOC) ist die Menge der Anmeldedaten, die Knoten verwenden, um innerhalb einer Fabric zu kommunizieren und sich zu identifizieren. Sie werden durch den Prozess Anfrage für das Signieren des betrieblichen Zertifikats des Knotens (Node Operational Certificate Signing Request, NOCSR) generiert.
NOCSR ist ein Verfahren, das auf dem in Betrieb zu nehmenden Knoten ausgeführt wird. Dabei werden mehrere kryptografische Elemente verknüpft und an den Commissioner gesendet, der das entsprechende NOC vom CA-Ökosystem anfordert. Abbildung 1 zeigt diesen Abhängigkeitsbaum und die Reihenfolge, in der einige Vorgänge ausgeführt werden.
Es ist wichtig, jedes kryptografische Element zu verstehen, um das SDK zu entwickeln. Eine vollständige Analyse ihrer Rolle und Auswirkungen würde jedoch den Rahmen dieses Leitfadens sprengen. Wichtig ist Folgendes:
- NOCs werden vom CA-Ökosystem in realen Produktions-Fabrics ausgestellt.
- NOCs sind kryptografisch an das eindeutige betriebliche Schlüsselpaar des Knotens (Node Operational Key Pair, NOKP) gebunden.
- NOKP wird vom in Betrieb zu nehmenden Knoten während des Inbetriebnahmeprozesses generiert.
- Die an das Ökosystem gesendeten NOCSR-Informationen enthalten den öffentlichen betrieblichen Schlüssel des Knotens. Der private betriebliche Schlüssel des Knotens wird jedoch niemals an den Commissioner oder die CA gesendet.
- Der NOCSR-Prozess verwendet Eingaben aus dem Attestierungsverfahren, signiert die CSRSR-Informationen und validiert so die Anfrage an die CA, ein vertrauenswürdiges NOC zu generieren.
Das Attestierungsverfahren wird vom Commissioner verwendet, um Folgendes zu bestätigen:
- Das Gerät hat die Matter Zertifizierung durchlaufen.
- Das Gerät ist tatsächlich das, was es vorgibt zu sein: Es beweist kryptografisch seinen Anbieter, seine Produkt-ID und andere Herstellungsinformationen.
Mehrere Administratoren
Knoten können auch in mehr als einer Fabric in Betrieb genommen werden. Diese Eigenschaft wird oft als „Multi-Admin“ bezeichnet. Ein Gerät kann beispielsweise sowohl in der Fabric des Herstellers als auch in der Fabric eines Cloud-Ökosystems in Betrieb genommen werden. Jede Fabric verarbeitet dabei eine andere Menge verschlüsselter Kommunikation und arbeitet unabhängig.
Da mehrere Fabrics gleichzeitig vorhanden sein können, hat ein Gerät möglicherweise mehrere Sätze betrieblicher Anmeldedaten für Knoten. Das Datenmodell des Knotens wird jedoch gemeinsam genutzt: Die Clusterattribute, Ereignisse und Aktionen sind für alle Fabrics gleich. Obwohl Thread und/oder WLAN-Anmeldedaten während des Inbetriebnahmeprozesses festgelegt werden, sind sie Teil des operativen Netzwerkclusters, werden von allen Fabrics gemeinsam genutzt und sind Teil des Datenmodells des Knotens, nicht der Fabric Anmeldedaten.