Teraz, gdy znamy już niektóre kluczowe pojęcia związane z węzłem, przeanalizujemy, co umożliwia urządzeniom komunikowanie się ze sobą.
Specyfikacja Matter wykorzystuje zaawansowane metody szyfrowania i odszyfrowywania informacji, a także bezpieczne mechanizmy zapewniające tożsamość węzła i udostępnianie danych logowania kryptograficznych.
Gdy grupa urządzeń w sieci współdzieli tę samą domenę bezpieczeństwa, a tym samym umożliwia bezpieczną komunikację między węzłami, nazywamy ją Fabric. Fabrics współdzielą ten sam certyfikat najwyższego poziomu urzędu certyfikacji (CA) (Root of Trust) oraz w kontekście CA unikalny 64-bitowy identyfikator o nazwie Fabric ID.
Dlatego proces wdrażania polega na przypisaniu danych logowania Fabric do nowego węzła, aby mógł on komunikować się z innymi węzłami w tej samej Fabric.
Dane logowania operacyjne
Źródło zaufania jest ustawiane w węźle podczas wdrażania przez komisarza, zwykle urządzenie z jakimś interfejsem GUI, np. smartfon, hub lub komputer, po otrzymaniu go od administratora domeny administracyjnej (ADM), który często jest ekosystemem pełniącym funkcję zaufanego głównego urzędu certyfikacji (CA).
Komisarz ma dostęp do CA. Dlatego w imieniu wdrażanego węzła lub Commissionee wysyła do CA prośbę o dane logowania operacyjne węzła. Dane logowania składają się z 2 części:
Identyfikator operacyjny węzła (lub operacyjny identyfikator węzła) to 64-bitowa liczba, która jednoznacznie identyfikuje każdy węzeł w Fabric.
Certyfikat operacyjny węzła (NOC) to zestaw danych logowania, których węzły używają do komunikowania się i identyfikowania się w Fabric. Są one generowane przez proces żądania podpisania certyfikatu operacyjnego węzła (NOCSR).
NOCSR to procedura, która jest uruchamiana w wdrażanym węźle. Łączy ona kilka elementów kryptograficznych, a następnie wysyła je do komisarza, który prosi ekosystem CA o odpowiedni NOC. Rysunek 1 przedstawia ten drzewo zależności i kolejność wykonywania niektórych operacji.
Chociaż zrozumienie każdego elementu kryptograficznego jest ważne w przypadku tworzenia pakietu SDK, pełna analiza ich roli i implikacji wykracza poza zakres tego przewodnika. Warto zauważyć, że:
- NOC są wydawane przez ekosystem CA w rzeczywistych środowiskach produkcyjnych.
- NOC są kryptograficznie powiązane z unikalną parą kluczy operacyjnych węzła (NOKP).
- NOKP jest generowany przez wdrażany węzeł podczas procesu wdrażania.
- Informacje NOCSR wysyłane do ekosystemu zawierają operacyjny klucz publiczny węzła, ale operacyjny klucz prywatny węzła nigdy nie jest wysyłany do komisarza ani do CA.
- Proces NOCSR wykorzystuje dane wejściowe z procedury atestacji, podpisując informacje CSRSR, a tym samym weryfikując prośbę o wygenerowanie przez CA zaufanego NOC.
Procedura atestacji to proces używany przez komisarza do potwierdzenia, że:
- urządzenie przeszło Matter certyfikację;
- urządzenie jest rzeczywiście tym, za co się podaje: kryptograficznie potwierdza swojego dostawcę, identyfikator produktu i inne informacje o produkcji.
Wielu administratorów
Węzły można też wdrażać w więcej niż 1 Fabric. Ta właściwość jest często nazywana wieloma administratorami. Możemy na przykład mieć urządzenie wdrożone zarówno w Fabric producenta, jak i w Fabric ekosystemu w chmurze, przy czym każda Fabric obsługuje inny zestaw zaszyfrowanych komunikatów i działa niezależnie.
Ponieważ może istnieć kilka Fabrics, urządzenie może mieć kilka zestawów danych logowania operacyjnych węzła. Model danych węzła jest jednak współdzielony: atrybuty klastra, zdarzenia i działania są wspólne dla Fabrics. Dlatego chociaż Thread lub dane logowania Wi-Fi są ustawiane podczas procesu wdrażania, należą one do klastra operacyjnego sieci, są współdzielone przez wszystkie Fabrics i stanowią część modelu danych węzła, a nie danych logowania Fabric.