Elvis Wiki - User contributions [en]

Matter

2024-02-06T11:23:19Z

MArcilla:

[[File:Matter_logo.jpg|thumb|Logo of Matter<ref name="logo"/>]]

'''Matter''' is an open standard that has been developed by the "Project Connected Home over IP" (CHIP) working group since 2019 and was first published in October 2022. It is intended to enable communication between devices from various manufacturers such as Google, Samsung, Apple and Amazon, thereby extending the boundaries of existing smart home networks.

== Protocol ==

It is an application layer protocol that is based on network protocols such as IPv6, Thread and BLE. Bridges are required to translate the network layers in order to be able to access Thread- or BLE-based devices from IP networks.

The Google Developer Center offers general documentation<ref name="matter-info" /> for Matter, which explains, for example, how a new device can connect to the Matter network.

[[File:Primer-matter-architecture.png|The Matter Stack in the TCP/IP and OSI Model]]

== Matter Virtual Device ==
The Google Developer Center provides resources for the development of Matter-based devices such as a sample app for connecting Matter devices <ref name="sample-app" /> or virtual Matter devices <ref name="virtual-device" /> for testing the interfaces.

A Matter Virtual Device (MVD) is an emulation of a Matter device and simulates the behavior of a device, e.g. switching a light switch on/off.

=== Possibilities ===
The virtual device can be built and started in several ways. A total of three possibilities have been found:

* Standalone
* Docker Image
* GitHub Repository

It turned out that the standalone is the best way to quickly set up an MVD. This requires an environment with a 64-bit x86 processor and at least Debian 11, Ubuntu 20.04 or MacOS.

==== GitHub Repository ====

# git clone https://github.com/project-chip/connectedhomeip
# Initialize the Matter project using "source scripts/activate.sh"
This variant was not pursued further, as the repository is resolved recursively and execution takes a lot of time.

==== Docker Image Repository ====

# docker pull us-docker.pkg.dev/nest-matter/docker-repo/virtual-device-image:latest
This approach downloads a Docker image that is larger than 10GB. Unpacked, it then has more than 30GB and is therefore also not suitable as a fast approach for development with Matter devices.

==== Standalone ====
The standalone Matter device was published relatively recently by Google, but is very easy to set up. Due to its comparatively small size of less than 70MB, it is easy to download and can be up and running within a few minutes.

https://i.imgur.com/Rjqabwb.png

Installation steps (Debian/Ubuntu)
# wget https://dl.google.com/mvd/mvd_1.3.0_amd64.deb
# sudo dpkg -i mvd_1.3.0_amd64.deb
# mvd

A GUI opens with which you can create an MVD.

[[File:MVD-Create.png|500px]]

In the new window, you can configure some settings for the device:

# Device Type - You can simulate several types of smart home devices
# Vendor ID - Unique certified ID for the vendor (possible values in development: 0xFFF1, 0xFFF2, 0xFFF3 and 0xFFF4)
# Product ID - Unique certified ID for the product (possible values in development: 0x8000 to 0x801F)
# Discriminator - If the same product occurs several times in the network, the discriminator can be used to differentiate between them.

=== Controller GUI ===
A GUI is required to communicate with the Matter device. There are two options for this:

==== Internal GUI via RPC ====
The standalone MVD is supplied with an integrated GUI, whereby the device is addressed on a different port (RPC port: 33000) than the Matter port (Matter port: 5540).
As soon as the MVD has been created, the control UI for the simulated device opens.

[[File:MVD-GUI.png|500px]]

==== GUI via Mobile App ====
The Google Developer Center has provided a CodeLab<ref name="sample-app" /> with which you can develop a simple Kotlin app for controlling Matter devices.
You can download a skeleton and the tutorial accompanies the developer to implement any missing code sections, which are marked with the comment "// CODELAB:".
They also offer a fully comprehensive solution to compare one's own implementation.

This app was then launched onto a mobile phone using USB debugging.

[[File:MVD-KotlinCode.png|500px]]

https://i.imgur.com/req0VHX.png

https://i.imgur.com/8jGIO3T.png

=== Connection ===
To connect to a Matter device on your mobile phone, you need the following prerequisites:

<li>Android Version - Version >= 8.1</li>
<li>Google Play Service - Version >= 22.36.15</li>
<li>Google Home App - Installed</li>

==== Steps ====
<li>To check whether the mobile phone is ready to connect Matter devices, check whether the selection Matter devices exists under Settings -> Google -> Devices and Sharing. </li>
<li>If not, you should try reinstalling the Google Home app, as downloading this app also downloads the dependencies required to connect to a Matter device.</li>

[[File:Matter-DevicesAndSharing.png|250px]]
[[File:Matter-Devices.png|250px]]

<li>If this step has been completed, a QR code will be generated in the MVD controller GUI.</li>

[[File:MVD-QR.png|500px]]

<li>Click on the + symbol on the app and a new window will open where you can scan the QR code with the camera.</li>

[[File:Matter-Scan.png|250px]]

<li>When connecting the device it should say that Matter Credentials have been created, commissioned and finally connected.</li>

[[File:Matter-Connected.png|250px]]

=== Security aspect ===

This topic was presented as part of elective project 2. The task was to recreate an attack using the MVD and show that it could be detected and mitigated during development. However, due to the newness of the standard, it is not yet widely established and therefore few vulnerabilities and exploits are known. Therefore, we could only try a DoS attack and thus prevent access to the MVD. It was not possible to evaluate whether a DoS occurred on the device itself or on the executing platform.

<references>
<ref name="logo">https://commons.wikimedia.org/wiki/File:Matter_logo.jpg</ref>
<ref name="sample-app">https://developers.home.google.com/codelabs/matter-sample-app#1</ref>
<ref name="matter-info">https://developers.home.google.com/matter/primer</ref>
<ref name="virtual-device">https://developers.home.google.com/tools/virtual-device</ref>
</references>

[[Category:Documentation]]

Matter

2024-01-28T20:12:03Z

MArcilla: /* Protokoll */

[[File:Matter_logo.jpg|thumb|Logo of Matter<ref name="logo"/>]]

'''Matter''' ist ein offener Standard, der von der Arbeitsgruppe "Project Connected Home over IP" (kurz CHIP) seit 2019 entwickelt und im Oktober 2022 erstmals publiziert wurde. Er soll die Kommunikation zwischen Geräten diverser Hersteller wie Google, Samsung, Apple und Amazon ermöglichen und damit die Grenzen bestehender Smart-Home Netze erweitern.

== Protokoll ==

Es handelt sich um ein Application-Layer-Protokoll, welches auf Netzwerkprotokolle wie IPv6, Thread und BLE aufsetzt. Um von IP-Netzwerken auf z.B. Thread- oder BLE-basierte Geräte zugreifen zu können werden Bridges benötigt, welche die Netzwerklayer übersetzen.

Das Google Developer Center bietet dabei eine allgemeine Dokumentation<ref name="matter-info" /> für Matter an, wo unter anderem erläutert wird, wie sich z.B. ein neues Gerät mit dem Matter Netzwerk verbinden kann.

[[File:Primer-matter-architecture.png|The Matter Stack in the TCP/IP and OSI Model]]

== Matter Virtual Device ==
Das Google Developer Center stellt Resourcen zur Entwicklung von Matter-basierten Geräten wie einer Sample App zum Verbinden von Matter-Geräten <ref name="sample-app" /> oder virtuellen Matter-Geräten <ref name="virtual-device" /> zum Testen der Schnittstellen bereit.

Ein Matter Virtual Device (MVD) ist eine Emulation eines Matter Devices und simuliert das Verhalten eines Gerätes z.B. das Ein-/Ausschalten eines Lichtschalters.

=== Möglichkeiten ===
Das Virtual Device kann man über mehrere Wege bauen und starten. Dazu wurden insgesamt drei Möglichkeiten gefunden:

* Standalone
* Docker Image
* GitHub Repository

Es hat sich herausgestellt, dass das Standalone am Besten geeignet ist, um schnell ein MVD einzurichten. Dazu wird eine Umgebung mit einem 64-bit x86 Prozessor und mindestens Debian 11, Ubuntu 20.04 oder MacOS benötigt.

==== GitHub Repository ====

# git clone https://github.com/project-chip/connectedhomeip
# Initialisieren des Matter-Projektes durch "source scripts/activate.sh"
Diese Variante wurde nicht weiter verfolgt, da das Repository rekursiv aufgelöst wird und das Klonen und Ausführen daher sehr viel Zeit in Anspruch nimmt.

==== Docker Image Repository ====

# docker pull us-docker.pkg.dev/nest-matter/docker-repo/virtual-device-image:latest
Dieser Ansatz lädt ein Docker Image herunter, welches größer als 10GB ist. Entpackt hat es dann mehr als 30GB und ist daher als schneller Ansatz für die Entwicklung mit Matter-Geräten ebenfalls nicht tauglich.

==== Standalone ====
Das Standalone-Matter-Device wurde relativ neu von Google publiziert, lässt sich aber sehr einfach aufsetzen. Durch seine vergleichsweise geringe Größe mit weniger als 70MB ist es einfach herunterzuladen und ist innerhalb weniger Minuten lauffähig.

https://i.imgur.com/Rjqabwb.png

Installationsschritte (Debian/Ubuntu)
# wget https://dl.google.com/mvd/mvd_1.3.0_amd64.deb
# sudo dpkg -i mvd_1.3.0_amd64.deb
# mvd

Es öffnet sich eine GUI, womit man ein MVD erstellen kann.

[[File:MVD-Create.png|500px]]

Beim neuen Fenster kann man einige Einstellungen bezüglich des Gerätes konfigurieren:

# Device Type - Man kann mehrere Arten von Smart Home Geräten simulieren
# Vendor ID - Eindeutige zertifierte ID für den Händler (Mögliche Werte in der Entwicklung: 0xFFF1, 0xFFF2, 0xFFF3 and 0xFFF4)
# Product ID - Eindeutige zertifizierte ID für das Produkt (Mögliche Werte in der Entwicklung: 0x8000 bis 0x801F)
# Discriminator - Im Fall, dass im Netzwerk das gleiche Produkt mehrmals auftritt, kann über den Discriminator unterschieden werden.

=== Controller GUI ===
Um mit dem Matter Device zu kommunizieren, wird eine GUI benötigt. Dazu gibt es wieder zwei Möglichkeiten:

==== Interne GUI über RPC ====
Das Standalone MVD wird mit einer integrierten GUI geliefert, wobei das Gerät auf einem anderen Port (RPC-Port: 33000) angesprochen wird, als den Matter Port (Matter-Port: 5540).
Sobald das MVD erstellt wurde, öffnet sich die Control-UI für das simulierte Gerät.

[[File:MVD-GUI.png|500px]]

==== GUI über Mobile App ====
Das Google Developer Center hat ein CodeLab<ref name="sample-app" /> zur Verfügung gestellt, womit man eine simple Kotlin-App für die Steuerung von Matter Geräten entwickeln kann.
Dazu kann man ein Skeleton herunterladen und das Tutorial begleitet den Entwickler, um etwaige fehlende Code-Stellen zu implementieren, die mit dem Kommentar "// CODELAB:" versehen sind.

Diese App wurde dann mittels USB-Debugging auf ein Handy gestartet.

[[File:MVD-KotlinCode.png|500px]]

https://i.imgur.com/req0VHX.png

https://i.imgur.com/8jGIO3T.png

=== Connection ===
Um sich am Handy mit einem Matter Gerät zu verbinden, braucht man folgende Voraussetzungen:

<li>Android Version - Version >= 8.1</li>
<li>Google Play Service - Version >= 22.36.15</li>
<li>Google Home App - Installiert</li>

==== Steps ====
<li>Zur Überprüfung, ob das Handy bereit ist, Matter Geräte zu verbinden, wird geschaut ob unter Einstellungen -> Google -> Devices and Sharing die Auswahl Matter devices existiert.</li>
<li>Falls nicht, sollte man versuchen die Google Home App neu zu installieren, da beim Download von dieser App gleichzeitig auch die benötigten Dependencies heruntergeladen werden, um sich mit einem Matter Gerät zu verbinden.</li>

[[File:Matter-DevicesAndSharing.png|250px]]
[[File:Matter-Devices.png|250px]]

<li>Sofern dieser Schritt geschafft worden ist, wird im MVD-Controller GUI ein QR-Code generiert.</li>

[[File:MVD-QR.png|500px]]

<li>Auf der App wird auf das + Symbol geklickt und es öffnet sich ein neues Fenster, wo man mit der Kamera den QR-Code scannen kann.</li>

[[File:Matter-Scan.png|250px]]

<li>Beim Verbinden des Gerätes sollte stehen, dass es Matter Credentials erstellt, Commissioned und schlussendlich auch verbunden ist.</li>

[[File:Matter-Connected.png|250px]]

<li></li>
=== Security Aspekt ===

Dieses Thema wurde im Rahmen des Wahlfachprojektes 2 vorgestellt. Die Aufgabe bestand darin, mit dem MVD einen Angriff nachzustellen und zu zeigen, dass dieser daher bereits während der Entwicklung erkennt und mitigiert werden könnte. Aufgrund der Neuheit des Standards ist dieser aber noch nicht in der Breite etabliert und daher sind auch noch wenige Vulnerabilities und Exploits bekannt. Daher konnten wir nur eine DoS Attacke ausprobieren und damit den Zugriff auf das MVD verhindern. Eine Differenzierung, ob es dabei zu einem DoS des Gerätes selbst oder der ausführenden Plattform kam, konnte nicht evaluiert werden.

<references>
<ref name="logo">https://commons.wikimedia.org/wiki/File:Matter_logo.jpg</ref>
<ref name="sample-app">https://developers.home.google.com/codelabs/matter-sample-app#1</ref>
<ref name="matter-info">https://developers.home.google.com/matter/primer</ref>
<ref name="virtual-device">https://developers.home.google.com/tools/virtual-device</ref>
</references>

[[Category:Documentation]]

Matter

2024-01-28T20:09:11Z

MArcilla: /* Matter Virtual Device */

[[File:Matter_logo.jpg|thumb|Logo of Matter<ref name="logo"/>]]

'''Matter''' ist ein offener Standard, der von der Arbeitsgruppe "Project Connected Home over IP" (kurz CHIP) seit 2019 entwickelt und im Oktober 2022 erstmals publiziert wurde. Er soll die Kommunikation zwischen Geräten diverser Hersteller wie Google, Samsung, Apple und Amazon ermöglichen und damit die Grenzen bestehender Smart-Home Netze erweitern.

== Protokoll ==

Es handelt sich um ein Application-Layer-Protokoll, welches auf Netzwerkprotokolle wie IPv6, Thread und BLE aufsetzt. Um von IP-Netzwerken auf z.B. Thread- oder BLE-basierte Geräte zugreifen zu können werden Bridges benötigt, welche die Netzwerklayer übersetzen.

[[File:Primer-matter-architecture.png|The Matter Stack in the TCP/IP and OSI Model]]

== Matter Virtual Device ==
Das Google Developer Center stellt Resourcen zur Entwicklung von Matter-basierten Geräten wie einer Sample App zum Verbinden von Matter-Geräten <ref name="sample-app" /> oder virtuellen Matter-Geräten <ref name="virtual-device" /> zum Testen der Schnittstellen bereit.

Ein Matter Virtual Device (MVD) ist eine Emulation eines Matter Devices und simuliert das Verhalten eines Gerätes z.B. das Ein-/Ausschalten eines Lichtschalters.

=== Möglichkeiten ===
Das Virtual Device kann man über mehrere Wege bauen und starten. Dazu wurden insgesamt drei Möglichkeiten gefunden:

* Standalone
* Docker Image
* GitHub Repository

Es hat sich herausgestellt, dass das Standalone am Besten geeignet ist, um schnell ein MVD einzurichten. Dazu wird eine Umgebung mit einem 64-bit x86 Prozessor und mindestens Debian 11, Ubuntu 20.04 oder MacOS benötigt.

==== GitHub Repository ====

# git clone https://github.com/project-chip/connectedhomeip
# Initialisieren des Matter-Projektes durch "source scripts/activate.sh"
Diese Variante wurde nicht weiter verfolgt, da das Repository rekursiv aufgelöst wird und das Klonen und Ausführen daher sehr viel Zeit in Anspruch nimmt.

==== Docker Image Repository ====

# docker pull us-docker.pkg.dev/nest-matter/docker-repo/virtual-device-image:latest
Dieser Ansatz lädt ein Docker Image herunter, welches größer als 10GB ist. Entpackt hat es dann mehr als 30GB und ist daher als schneller Ansatz für die Entwicklung mit Matter-Geräten ebenfalls nicht tauglich.

==== Standalone ====
Das Standalone-Matter-Device wurde relativ neu von Google publiziert, lässt sich aber sehr einfach aufsetzen. Durch seine vergleichsweise geringe Größe mit weniger als 70MB ist es einfach herunterzuladen und ist innerhalb weniger Minuten lauffähig.

https://i.imgur.com/Rjqabwb.png

Installationsschritte (Debian/Ubuntu)
# wget https://dl.google.com/mvd/mvd_1.3.0_amd64.deb
# sudo dpkg -i mvd_1.3.0_amd64.deb
# mvd

Es öffnet sich eine GUI, womit man ein MVD erstellen kann.

[[File:MVD-Create.png|500px]]

Beim neuen Fenster kann man einige Einstellungen bezüglich des Gerätes konfigurieren:

# Device Type - Man kann mehrere Arten von Smart Home Geräten simulieren
# Vendor ID - Eindeutige zertifierte ID für den Händler (Mögliche Werte in der Entwicklung: 0xFFF1, 0xFFF2, 0xFFF3 and 0xFFF4)
# Product ID - Eindeutige zertifizierte ID für das Produkt (Mögliche Werte in der Entwicklung: 0x8000 bis 0x801F)
# Discriminator - Im Fall, dass im Netzwerk das gleiche Produkt mehrmals auftritt, kann über den Discriminator unterschieden werden.

=== Controller GUI ===
Um mit dem Matter Device zu kommunizieren, wird eine GUI benötigt. Dazu gibt es wieder zwei Möglichkeiten:

==== Interne GUI über RPC ====
Das Standalone MVD wird mit einer integrierten GUI geliefert, wobei das Gerät auf einem anderen Port (RPC-Port: 33000) angesprochen wird, als den Matter Port (Matter-Port: 5540).
Sobald das MVD erstellt wurde, öffnet sich die Control-UI für das simulierte Gerät.

[[File:MVD-GUI.png|500px]]

==== GUI über Mobile App ====
Das Google Developer Center hat ein CodeLab<ref name="sample-app" /> zur Verfügung gestellt, womit man eine simple Kotlin-App für die Steuerung von Matter Geräten entwickeln kann.
Dazu kann man ein Skeleton herunterladen und das Tutorial begleitet den Entwickler, um etwaige fehlende Code-Stellen zu implementieren, die mit dem Kommentar "// CODELAB:" versehen sind.

Diese App wurde dann mittels USB-Debugging auf ein Handy gestartet.

[[File:MVD-KotlinCode.png|500px]]

https://i.imgur.com/req0VHX.png

https://i.imgur.com/8jGIO3T.png

=== Connection ===
Um sich am Handy mit einem Matter Gerät zu verbinden, braucht man folgende Voraussetzungen:

<li>Android Version - Version >= 8.1</li>
<li>Google Play Service - Version >= 22.36.15</li>
<li>Google Home App - Installiert</li>

==== Steps ====
<li>Zur Überprüfung, ob das Handy bereit ist, Matter Geräte zu verbinden, wird geschaut ob unter Einstellungen -> Google -> Devices and Sharing die Auswahl Matter devices existiert.</li>
<li>Falls nicht, sollte man versuchen die Google Home App neu zu installieren, da beim Download von dieser App gleichzeitig auch die benötigten Dependencies heruntergeladen werden, um sich mit einem Matter Gerät zu verbinden.</li>

[[File:Matter-DevicesAndSharing.png|250px]]
[[File:Matter-Devices.png|250px]]

<li>Sofern dieser Schritt geschafft worden ist, wird im MVD-Controller GUI ein QR-Code generiert.</li>

[[File:MVD-QR.png|500px]]

<li>Auf der App wird auf das + Symbol geklickt und es öffnet sich ein neues Fenster, wo man mit der Kamera den QR-Code scannen kann.</li>

[[File:Matter-Scan.png|250px]]

<li>Beim Verbinden des Gerätes sollte stehen, dass es Matter Credentials erstellt, Commissioned und schlussendlich auch verbunden ist.</li>

[[File:Matter-Connected.png|250px]]

<li></li>
=== Security Aspekt ===

Dieses Thema wurde im Rahmen des Wahlfachprojektes 2 vorgestellt. Die Aufgabe bestand darin, mit dem MVD einen Angriff nachzustellen und zu zeigen, dass dieser daher bereits während der Entwicklung erkennt und mitigiert werden könnte. Aufgrund der Neuheit des Standards ist dieser aber noch nicht in der Breite etabliert und daher sind auch noch wenige Vulnerabilities und Exploits bekannt. Daher konnten wir nur eine DoS Attacke ausprobieren und damit den Zugriff auf das MVD verhindern. Eine Differenzierung, ob es dabei zu einem DoS des Gerätes selbst oder der ausführenden Plattform kam, konnte nicht evaluiert werden.

<references>
<ref name="logo">https://commons.wikimedia.org/wiki/File:Matter_logo.jpg</ref>
<ref name="sample-app">https://developers.home.google.com/codelabs/matter-sample-app#1</ref>
<ref name="matter-info">https://developers.home.google.com/matter/primer</ref>
<ref name="virtual-device">https://developers.home.google.com/tools/virtual-device</ref>
</references>

[[Category:Documentation]]

Matter

2024-01-28T20:07:22Z

MArcilla: /* Matter Virtual Device */

[[File:Matter_logo.jpg|thumb|Logo of Matter<ref name="logo"/>]]

'''Matter''' ist ein offener Standard, der von der Arbeitsgruppe "Project Connected Home over IP" (kurz CHIP) seit 2019 entwickelt und im Oktober 2022 erstmals publiziert wurde. Er soll die Kommunikation zwischen Geräten diverser Hersteller wie Google, Samsung, Apple und Amazon ermöglichen und damit die Grenzen bestehender Smart-Home Netze erweitern.

== Protokoll ==

Es handelt sich um ein Application-Layer-Protokoll, welches auf Netzwerkprotokolle wie IPv6, Thread und BLE aufsetzt. Um von IP-Netzwerken auf z.B. Thread- oder BLE-basierte Geräte zugreifen zu können werden Bridges benötigt, welche die Netzwerklayer übersetzen.

[[File:Primer-matter-architecture.png|The Matter Stack in the TCP/IP and OSI Model]]

== Matter Virtual Device ==
Das Google Developer Center stellt Resourcen zur Entwicklung von Matter-basierten Geräten wie einer Sample App zum Verbinden von Matter-Geräten <ref name="sample-app" /> oder virtuellen Matter-Geräten <ref name="virtual-device" /> zum Testen der Schnittstellen bereit. Das Developer Center bietet auch eine allgemeine Dokumentation für Matter an.<ref name="matter-info" />

Ein Matter Virtual Device (MVD) ist eine Emulation eines Matter Devices und simuliert das Verhalten eines Gerätes z.B. das Ein-/Ausschalten eines Lichtschalters.

=== Möglichkeiten ===
Das Virtual Device kann man über mehrere Wege bauen und starten. Dazu wurden insgesamt drei Möglichkeiten gefunden:

* Standalone
* Docker Image
* GitHub Repository

Es hat sich herausgestellt, dass das Standalone am Besten geeignet ist, um schnell ein MVD einzurichten. Dazu wird eine Umgebung mit einem 64-bit x86 Prozessor und mindestens Debian 11, Ubuntu 20.04 oder MacOS benötigt.

==== GitHub Repository ====

# git clone https://github.com/project-chip/connectedhomeip
# Initialisieren des Matter-Projektes durch "source scripts/activate.sh"
Diese Variante wurde nicht weiter verfolgt, da das Repository rekursiv aufgelöst wird und das Klonen und Ausführen daher sehr viel Zeit in Anspruch nimmt.

==== Docker Image Repository ====

# docker pull us-docker.pkg.dev/nest-matter/docker-repo/virtual-device-image:latest
Dieser Ansatz lädt ein Docker Image herunter, welches größer als 10GB ist. Entpackt hat es dann mehr als 30GB und ist daher als schneller Ansatz für die Entwicklung mit Matter-Geräten ebenfalls nicht tauglich.

==== Standalone ====
Das Standalone-Matter-Device wurde relativ neu von Google publiziert, lässt sich aber sehr einfach aufsetzen. Durch seine vergleichsweise geringe Größe mit weniger als 70MB ist es einfach herunterzuladen und ist innerhalb weniger Minuten lauffähig.

https://i.imgur.com/Rjqabwb.png

Installationsschritte (Debian/Ubuntu)
# wget https://dl.google.com/mvd/mvd_1.3.0_amd64.deb
# sudo dpkg -i mvd_1.3.0_amd64.deb
# mvd

Es öffnet sich eine GUI, womit man ein MVD erstellen kann.

[[File:MVD-Create.png|500px]]

Beim neuen Fenster kann man einige Einstellungen bezüglich des Gerätes konfigurieren:

# Device Type - Man kann mehrere Arten von Smart Home Geräten simulieren
# Vendor ID - Eindeutige zertifierte ID für den Händler (Mögliche Werte in der Entwicklung: 0xFFF1, 0xFFF2, 0xFFF3 and 0xFFF4)
# Product ID - Eindeutige zertifizierte ID für das Produkt (Mögliche Werte in der Entwicklung: 0x8000 bis 0x801F)
# Discriminator - Im Fall, dass im Netzwerk das gleiche Produkt mehrmals auftritt, kann über den Discriminator unterschieden werden.

=== Controller GUI ===
Um mit dem Matter Device zu kommunizieren, wird eine GUI benötigt. Dazu gibt es wieder zwei Möglichkeiten:

==== Interne GUI über RPC ====
Das Standalone MVD wird mit einer integrierten GUI geliefert, wobei das Gerät auf einem anderen Port (RPC-Port: 33000) angesprochen wird, als den Matter Port (Matter-Port: 5540).
Sobald das MVD erstellt wurde, öffnet sich die Control-UI für das simulierte Gerät.

[[File:MVD-GUI.png|500px]]

==== GUI über Mobile App ====
Das Google Developer Center hat ein CodeLab<ref name="sample-app" /> zur Verfügung gestellt, womit man eine simple Kotlin-App für die Steuerung von Matter Geräten entwickeln kann.
Dazu kann man ein Skeleton herunterladen und das Tutorial begleitet den Entwickler, um etwaige fehlende Code-Stellen zu implementieren, die mit dem Kommentar "// CODELAB:" versehen sind.

Diese App wurde dann mittels USB-Debugging auf ein Handy gestartet.

[[File:MVD-KotlinCode.png|500px]]

https://i.imgur.com/req0VHX.png

https://i.imgur.com/8jGIO3T.png

=== Connection ===
Um sich am Handy mit einem Matter Gerät zu verbinden, braucht man folgende Voraussetzungen:

<li>Android Version - Version >= 8.1</li>
<li>Google Play Service - Version >= 22.36.15</li>
<li>Google Home App - Installiert</li>

==== Steps ====
<li>Zur Überprüfung, ob das Handy bereit ist, Matter Geräte zu verbinden, wird geschaut ob unter Einstellungen -> Google -> Devices and Sharing die Auswahl Matter devices existiert.</li>
<li>Falls nicht, sollte man versuchen die Google Home App neu zu installieren, da beim Download von dieser App gleichzeitig auch die benötigten Dependencies heruntergeladen werden, um sich mit einem Matter Gerät zu verbinden.</li>

[[File:Matter-DevicesAndSharing.png|250px]]
[[File:Matter-Devices.png|250px]]

<li>Sofern dieser Schritt geschafft worden ist, wird im MVD-Controller GUI ein QR-Code generiert.</li>

[[File:MVD-QR.png|500px]]

<li>Auf der App wird auf das + Symbol geklickt und es öffnet sich ein neues Fenster, wo man mit der Kamera den QR-Code scannen kann.</li>

[[File:Matter-Scan.png|250px]]

<li>Beim Verbinden des Gerätes sollte stehen, dass es Matter Credentials erstellt, Commissioned und schlussendlich auch verbunden ist.</li>

[[File:Matter-Connected.png|250px]]

<li></li>
=== Security Aspekt ===

Dieses Thema wurde im Rahmen des Wahlfachprojektes 2 vorgestellt. Die Aufgabe bestand darin, mit dem MVD einen Angriff nachzustellen und zu zeigen, dass dieser daher bereits während der Entwicklung erkennt und mitigiert werden könnte. Aufgrund der Neuheit des Standards ist dieser aber noch nicht in der Breite etabliert und daher sind auch noch wenige Vulnerabilities und Exploits bekannt. Daher konnten wir nur eine DoS Attacke ausprobieren und damit den Zugriff auf das MVD verhindern. Eine Differenzierung, ob es dabei zu einem DoS des Gerätes selbst oder der ausführenden Plattform kam, konnte nicht evaluiert werden.

<references>
<ref name="logo">https://commons.wikimedia.org/wiki/File:Matter_logo.jpg</ref>
<ref name="sample-app">https://developers.home.google.com/codelabs/matter-sample-app#1</ref>
<ref name="matter-info">https://developers.home.google.com/matter/primer</ref>
<ref name="virtual-device">https://developers.home.google.com/tools/virtual-device</ref>
</references>

[[Category:Documentation]]

Matter

2024-01-28T20:07:09Z

MArcilla: /* Matter Virtual Device */

[[File:Matter_logo.jpg|thumb|Logo of Matter<ref name="logo"/>]]

'''Matter''' ist ein offener Standard, der von der Arbeitsgruppe "Project Connected Home over IP" (kurz CHIP) seit 2019 entwickelt und im Oktober 2022 erstmals publiziert wurde. Er soll die Kommunikation zwischen Geräten diverser Hersteller wie Google, Samsung, Apple und Amazon ermöglichen und damit die Grenzen bestehender Smart-Home Netze erweitern.

== Protokoll ==

Es handelt sich um ein Application-Layer-Protokoll, welches auf Netzwerkprotokolle wie IPv6, Thread und BLE aufsetzt. Um von IP-Netzwerken auf z.B. Thread- oder BLE-basierte Geräte zugreifen zu können werden Bridges benötigt, welche die Netzwerklayer übersetzen.

[[File:Primer-matter-architecture.png|The Matter Stack in the TCP/IP and OSI Model]]

== Matter Virtual Device ==
Das Google Developer Center stellt Resourcen zur Entwicklung von Matter-basierten Geräten wie einer Sample App zum Verbinden von Matter-Geräten <ref name="sample-app" /> oder virtuellen Matter-Geräten <ref name="virtual-device" /> zum Testen der Schnittstellen bereit. Das Developer Center bietet auch eine allgemeine Dokumentation für Matter an.<ref name="matter-info" />

Ein Matter Virtual Device (MVD) ist eine Emulation eines Matter Devices und simuliert das Verhalten eines Gerätes z.B. das Ein-/Ausschalten eines Lichtschalters.

=== Möglichkeiten ===
Das Virtual Device kann man über mehrere Wege bauen und starten. Dazu wurden insgesamt drei Möglichkeiten gefunden:

* Standalone
* Docker Image
* GitHub Repository

Es hat sich herausgestellt, dass das Standalone am Besten geeignet ist, um schnell ein MVD einzurichten. Dazu wird eine Umgebung mit einem 64-bit x86 Prozessor und mindestens Debian 11, Ubuntu 20.04 oder MacOS benötigt.

==== GitHub Repository ====

# git clone https://github.com/project-chip/connectedhomeip
# Initialisieren des Matter-Projektes durch "source scripts/activate.sh"
Diese Variante wurde nicht weiter verfolgt, da das Repository rekursiv aufgelöst wird und das Klonen und Ausführen daher sehr viel Zeit in Anspruch nimmt.

==== Docker Image Repository ====

# docker pull us-docker.pkg.dev/nest-matter/docker-repo/virtual-device-image:latest
Dieser Ansatz lädt ein Docker Image herunter, welches größer als 10GB ist. Entpackt hat es dann mehr als 30GB und ist daher als schneller Ansatz für die Entwicklung mit Matter-Geräten ebenfalls nicht tauglich.

==== Standalone ====
Das Standalone-Matter-Device wurde relativ neu von Google publiziert, lässt sich aber sehr einfach aufsetzen. Durch seine vergleichsweise geringe Größe mit weniger als 70MB ist es einfach herunterzuladen und ist innerhalb weniger Minuten lauffähig.

https://i.imgur.com/Rjqabwb.png

Installationsschritte (Debian/Ubuntu)
# wget https://dl.google.com/mvd/mvd_1.3.0_amd64.deb
# sudo dpkg -i mvd_1.3.0_amd64.deb
# mvd

Es öffnet sich eine GUI, womit man ein MVD erstellen kann.

[[File:MVD-Create.png|500px]]

Beim neuen Fenster kann man einige Einstellungen bezüglich des Gerätes konfigurieren:

# Device Type - Man kann mehrere Arten von Smart Home Geräten simulieren
# Vendor ID - Eindeutige zertifierte ID für den Händler (Mögliche Werte in der Entwicklung: 0xFFF1, 0xFFF2, 0xFFF3 and 0xFFF4)
# Product ID - Eindeutige zertifizierte ID für das Produkt (Mögliche Werte in der Entwicklung: 0x8000 bis 0x801F)
# Discriminator - Im Fall, dass im Netzwerk das gleiche Produkt mehrmals auftritt, kann über den Discriminator unterschieden werden.

=== Controller GUI ===
Um mit dem Matter Device zu kommunizieren, wird eine GUI benötigt. Dazu gibt es wieder zwei Möglichkeiten:

==== Internal GUI über RPC ====
Das Standalone MVD wird mit einer integrierten GUI geliefert, wobei das Gerät auf einem anderen Port (RPC-Port: 33000) angesprochen wird, als den Matter Port (Matter-Port: 5540).
Sobald das MVD erstellt wurde, öffnet sich die Control-UI für das simulierte Gerät.

[[File:MVD-GUI.png|500px]]

==== GUI über Mobile App ====
Das Google Developer Center hat ein CodeLab<ref name="sample-app" /> zur Verfügung gestellt, womit man eine simple Kotlin-App für die Steuerung von Matter Geräten entwickeln kann.
Dazu kann man ein Skeleton herunterladen und das Tutorial begleitet den Entwickler, um etwaige fehlende Code-Stellen zu implementieren, die mit dem Kommentar "// CODELAB:" versehen sind.

Diese App wurde dann mittels USB-Debugging auf ein Handy gestartet.

[[File:MVD-KotlinCode.png|500px]]

https://i.imgur.com/req0VHX.png

https://i.imgur.com/8jGIO3T.png

=== Connection ===
Um sich am Handy mit einem Matter Gerät zu verbinden, braucht man folgende Voraussetzungen:

<li>Android Version - Version >= 8.1</li>
<li>Google Play Service - Version >= 22.36.15</li>
<li>Google Home App - Installiert</li>

==== Steps ====
<li>Zur Überprüfung, ob das Handy bereit ist, Matter Geräte zu verbinden, wird geschaut ob unter Einstellungen -> Google -> Devices and Sharing die Auswahl Matter devices existiert.</li>
<li>Falls nicht, sollte man versuchen die Google Home App neu zu installieren, da beim Download von dieser App gleichzeitig auch die benötigten Dependencies heruntergeladen werden, um sich mit einem Matter Gerät zu verbinden.</li>

[[File:Matter-DevicesAndSharing.png|250px]]
[[File:Matter-Devices.png|250px]]

<li>Sofern dieser Schritt geschafft worden ist, wird im MVD-Controller GUI ein QR-Code generiert.</li>

[[File:MVD-QR.png|500px]]

<li>Auf der App wird auf das + Symbol geklickt und es öffnet sich ein neues Fenster, wo man mit der Kamera den QR-Code scannen kann.</li>

[[File:Matter-Scan.png|250px]]

<li>Beim Verbinden des Gerätes sollte stehen, dass es Matter Credentials erstellt, Commissioned und schlussendlich auch verbunden ist.</li>

[[File:Matter-Connected.png|250px]]

<li></li>
=== Security Aspekt ===

Dieses Thema wurde im Rahmen des Wahlfachprojektes 2 vorgestellt. Die Aufgabe bestand darin, mit dem MVD einen Angriff nachzustellen und zu zeigen, dass dieser daher bereits während der Entwicklung erkennt und mitigiert werden könnte. Aufgrund der Neuheit des Standards ist dieser aber noch nicht in der Breite etabliert und daher sind auch noch wenige Vulnerabilities und Exploits bekannt. Daher konnten wir nur eine DoS Attacke ausprobieren und damit den Zugriff auf das MVD verhindern. Eine Differenzierung, ob es dabei zu einem DoS des Gerätes selbst oder der ausführenden Plattform kam, konnte nicht evaluiert werden.

<references>
<ref name="logo">https://commons.wikimedia.org/wiki/File:Matter_logo.jpg</ref>
<ref name="sample-app">https://developers.home.google.com/codelabs/matter-sample-app#1</ref>
<ref name="matter-info">https://developers.home.google.com/matter/primer</ref>
<ref name="virtual-device">https://developers.home.google.com/tools/virtual-device</ref>
</references>

[[Category:Documentation]]

Matter

2024-01-28T07:52:22Z

MArcilla: /* Security Aspekt */

[[File:Matter_logo.jpg|thumb|Logo of Matter<ref name="logo"/>]]

'''Matter''' ist ein offener Standard, der von der Arbeitsgruppe "Project Connected Home over IP" (kurz CHIP) seit 2019 entwickelt und im Oktober 2022 erstmals publiziert wurde. Er soll die Kommunikation zwischen Geräten diverser Hersteller wie Google, Samsung, Apple und Amazon ermöglichen und damit die Grenzen bestehender Smart-Home Netze erweitern.

== Protokoll ==

Es handelt sich um ein Application-Layer-Protokoll, welches auf Netzwerkprotokolle wie IPv6, Thread und BLE aufsetzt. Um von IP-Netzwerken auf z.B. Thread- oder BLE-basierte Geräte zugreifen zu können werden Bridges benötigt, welche die Netzwerklayer übersetzen.

[[File:Primer-matter-architecture.png|The Matter Stack in the TCP/IP and OSI Model]]

== Matter Virtual Device ==
Das Google Developer Center stellt Resourcen zur Entwicklung von Matter-basierten Geräten wie einer Sample App zum Verbinden von Matter-Geräten <ref name="sample-app" /> oder virtuellen Matter-Geräten <ref name="virtual-device" /> zum Testen der Schnittstellen bereit.

Ein Matter Virtual Device (MVD) ist eine Emulation eines Matter Devices und simuliert das Verhalten eines Gerätes z.B. das Ein-/Ausschalten eines Lichtschalters.

=== Möglichkeiten ===
Das Virtual Device kann man über mehrere Wege bauen und starten. Dazu wurden insgesamt drei Möglichkeiten gefunden:

* Standalone
* Docker Image
* GitHub Repository

Es hat sich herausgestellt, dass das Standalone am Besten geeignet ist, um schnell ein MVD einzurichten. Dazu wird eine Umgebung mit einem 64-bit x86 Prozessor und mindestens Debian 11, Ubuntu 20.04 oder MacOS benötigt.

==== GitHub Repository ====

# git clone https://github.com/project-chip/connectedhomeip
# Initialisieren des Matter-Projektes durch "source scripts/activate.sh"
Diese Variante wurde nicht weiter verfolgt, da das Repository rekursiv aufgelöst wird und das Klonen und Ausführen daher sehr viel Zeit in Anspruch nimmt.

==== Docker Image Repository ====

# docker pull us-docker.pkg.dev/nest-matter/docker-repo/virtual-device-image:latest
Dieser Ansatz lädt ein Docker Image herunter, welches größer als 10GB ist. Entpackt hat es dann mehr als 30GB und ist daher als schneller Ansatz für die Entwicklung mit Matter-Geräten ebenfalls nicht tauglich.

==== Standalone ====
Das Standalone-Matter-Device wurde relativ neu von Google publiziert, lässt sich aber sehr einfach aufsetzen. Durch seine vergleichsweise geringe Größe mit weniger als 70MB ist es einfach herunterzuladen und ist innerhalb weniger Minuten lauffähig.

https://i.imgur.com/Rjqabwb.png

Installationsschritte (Debian/Ubuntu)
# wget https://dl.google.com/mvd/mvd_1.3.0_amd64.deb
# sudo dpkg -i mvd_1.3.0_amd64.deb
# mvd

Es öffnet sich eine GUI, womit man ein MVD erstellen kann.

[[File:MVD-Create.png|500px]]

Beim neuen Fenster kann man einige Einstellungen bezüglich des Gerätes konfigurieren:

# Device Type - Man kann mehrere Arten von Smart Home Geräten simulieren
# Vendor ID - Eindeutige zertifierte ID für den Händler (Mögliche Werte in der Entwicklung: 0xFFF1, 0xFFF2, 0xFFF3 and 0xFFF4)
# Product ID - Eindeutige zertifizierte ID für das Produkt (Mögliche Werte in der Entwicklung: 0x8000 bis 0x801F)
# Discriminator - Im Fall, dass im Netzwerk das gleiche Produkt mehrmals auftritt, kann über den Discriminator unterschieden werden.

=== Controller GUI ===
Um mit dem Matter Device zu kommunizieren, wird eine GUI benötigt. Dazu gibt es wieder zwei Möglichkeiten:

==== Internal GUI über RPC ====
Das Standalone MVD wird mit einer integrierten GUI geliefert, wobei das Gerät auf einem anderen Port (RPC-Port: 33000) angesprochen wird, als den Matter Port (Matter-Port: 5540).
Sobald das MVD erstellt wurde, öffnet sich die Control-UI für das simulierte Gerät.

[[File:MVD-GUI.png|500px]]

==== GUI über Mobile App ====
Das Google Developer Center hat ein CodeLab<ref name="sample-app" /> zur Verfügung gestellt, womit man eine simple Kotlin-App für die Steuerung von Matter Geräten entwickeln kann.
Dazu kann man ein Skeleton herunterladen und das Tutorial begleitet den Entwickler, um etwaige fehlende Code-Stellen zu implementieren, die mit dem Kommentar "// CODELAB:" versehen sind.

Diese App wurde dann mittels USB-Debugging auf ein Handy gestartet.

[[File:MVD-KotlinCode.png|500px]]

https://i.imgur.com/req0VHX.png

https://i.imgur.com/8jGIO3T.png

=== Connection ===
Um sich am Handy mit einem Matter Gerät zu verbinden, braucht man folgende Voraussetzungen:

<li>Android Version - Version >= 8.1</li>
<li>Google Play Service - Version >= 22.36.15</li>
<li>Google Home App - Installiert</li>

==== Steps ====
<li>Zur Überprüfung, ob das Handy bereit ist, Matter Geräte zu verbinden, wird geschaut ob unter Einstellungen -> Google -> Devices and Sharing die Auswahl Matter devices existiert.</li>
<li>Falls nicht, sollte man versuchen die Google Home App neu zu installieren, da beim Download von dieser App gleichzeitig auch die benötigten Dependencies heruntergeladen werden, um sich mit einem Matter Gerät zu verbinden.</li>

[[File:Matter-DevicesAndSharing.png|250px]]
[[File:Matter-Devices.png|250px]]

<li>Sofern dieser Schritt geschafft worden ist, wird im MVD-Controller GUI ein QR-Code generiert.</li>

[[File:MVD-QR.png|500px]]

<li>Auf der App wird auf das + Symbol geklickt und es öffnet sich ein neues Fenster, wo man mit der Kamera den QR-Code scannen kann.</li>

[[File:Matter-Scan.png|250px]]

<li>Beim Verbinden des Gerätes sollte stehen, dass es Matter Credentials erstellt, Commissioned und schlussendlich auch verbunden ist.</li>

[[File:Matter-Connected.png|250px]]

<li></li>
=== Security Aspekt ===

Dieses Thema wurde im Rahmen des Wahlfachprojektes 2 vorgestellt. Die Aufgabe bestand darin, mit dem MVD einen Angriff nachzustellen und zu zeigen, dass dieser daher bereits während der Entwicklung erkennt und mitigiert werden könnte. Aufgrund der Neuheit des Standards ist dieser aber noch nicht in der Breite etabliert und daher sind auch noch wenige Vulnerabilities und Exploits bekannt. Daher konnten wir nur eine DoS Attacke ausprobieren und damit den Zugriff auf das MVD verhindern. Eine Differenzierung, ob es dabei zu einem DoS des Gerätes selbst oder der ausführenden Plattform kam, konnte nicht evaluiert werden.

<references>
<ref name="logo">https://commons.wikimedia.org/wiki/File:Matter_logo.jpg</ref>
<ref name="sample-app">https://developers.home.google.com/codelabs/matter-sample-app#1</ref>
<ref name="virtual-device">https://developers.home.google.com/tools/virtual-device</ref>
</references>

[[Category:Documentation]]

Matter

2024-01-28T07:52:09Z

MArcilla: /* Security Aspekt */

[[File:Matter_logo.jpg|thumb|Logo of Matter<ref name="logo"/>]]

'''Matter''' ist ein offener Standard, der von der Arbeitsgruppe "Project Connected Home over IP" (kurz CHIP) seit 2019 entwickelt und im Oktober 2022 erstmals publiziert wurde. Er soll die Kommunikation zwischen Geräten diverser Hersteller wie Google, Samsung, Apple und Amazon ermöglichen und damit die Grenzen bestehender Smart-Home Netze erweitern.

== Protokoll ==

Es handelt sich um ein Application-Layer-Protokoll, welches auf Netzwerkprotokolle wie IPv6, Thread und BLE aufsetzt. Um von IP-Netzwerken auf z.B. Thread- oder BLE-basierte Geräte zugreifen zu können werden Bridges benötigt, welche die Netzwerklayer übersetzen.

[[File:Primer-matter-architecture.png|The Matter Stack in the TCP/IP and OSI Model]]

== Matter Virtual Device ==
Das Google Developer Center stellt Resourcen zur Entwicklung von Matter-basierten Geräten wie einer Sample App zum Verbinden von Matter-Geräten <ref name="sample-app" /> oder virtuellen Matter-Geräten <ref name="virtual-device" /> zum Testen der Schnittstellen bereit.

Ein Matter Virtual Device (MVD) ist eine Emulation eines Matter Devices und simuliert das Verhalten eines Gerätes z.B. das Ein-/Ausschalten eines Lichtschalters.

=== Möglichkeiten ===
Das Virtual Device kann man über mehrere Wege bauen und starten. Dazu wurden insgesamt drei Möglichkeiten gefunden:

* Standalone
* Docker Image
* GitHub Repository

Es hat sich herausgestellt, dass das Standalone am Besten geeignet ist, um schnell ein MVD einzurichten. Dazu wird eine Umgebung mit einem 64-bit x86 Prozessor und mindestens Debian 11, Ubuntu 20.04 oder MacOS benötigt.

==== GitHub Repository ====

# git clone https://github.com/project-chip/connectedhomeip
# Initialisieren des Matter-Projektes durch "source scripts/activate.sh"
Diese Variante wurde nicht weiter verfolgt, da das Repository rekursiv aufgelöst wird und das Klonen und Ausführen daher sehr viel Zeit in Anspruch nimmt.

==== Docker Image Repository ====

# docker pull us-docker.pkg.dev/nest-matter/docker-repo/virtual-device-image:latest
Dieser Ansatz lädt ein Docker Image herunter, welches größer als 10GB ist. Entpackt hat es dann mehr als 30GB und ist daher als schneller Ansatz für die Entwicklung mit Matter-Geräten ebenfalls nicht tauglich.

==== Standalone ====
Das Standalone-Matter-Device wurde relativ neu von Google publiziert, lässt sich aber sehr einfach aufsetzen. Durch seine vergleichsweise geringe Größe mit weniger als 70MB ist es einfach herunterzuladen und ist innerhalb weniger Minuten lauffähig.

https://i.imgur.com/Rjqabwb.png

Installationsschritte (Debian/Ubuntu)
# wget https://dl.google.com/mvd/mvd_1.3.0_amd64.deb
# sudo dpkg -i mvd_1.3.0_amd64.deb
# mvd

Es öffnet sich eine GUI, womit man ein MVD erstellen kann.

[[File:MVD-Create.png|500px]]

Beim neuen Fenster kann man einige Einstellungen bezüglich des Gerätes konfigurieren:

# Device Type - Man kann mehrere Arten von Smart Home Geräten simulieren
# Vendor ID - Eindeutige zertifierte ID für den Händler (Mögliche Werte in der Entwicklung: 0xFFF1, 0xFFF2, 0xFFF3 and 0xFFF4)
# Product ID - Eindeutige zertifizierte ID für das Produkt (Mögliche Werte in der Entwicklung: 0x8000 bis 0x801F)
# Discriminator - Im Fall, dass im Netzwerk das gleiche Produkt mehrmals auftritt, kann über den Discriminator unterschieden werden.

=== Controller GUI ===
Um mit dem Matter Device zu kommunizieren, wird eine GUI benötigt. Dazu gibt es wieder zwei Möglichkeiten:

==== Internal GUI über RPC ====
Das Standalone MVD wird mit einer integrierten GUI geliefert, wobei das Gerät auf einem anderen Port (RPC-Port: 33000) angesprochen wird, als den Matter Port (Matter-Port: 5540).
Sobald das MVD erstellt wurde, öffnet sich die Control-UI für das simulierte Gerät.

[[File:MVD-GUI.png|500px]]

==== GUI über Mobile App ====
Das Google Developer Center hat ein CodeLab<ref name="sample-app" /> zur Verfügung gestellt, womit man eine simple Kotlin-App für die Steuerung von Matter Geräten entwickeln kann.
Dazu kann man ein Skeleton herunterladen und das Tutorial begleitet den Entwickler, um etwaige fehlende Code-Stellen zu implementieren, die mit dem Kommentar "// CODELAB:" versehen sind.

Diese App wurde dann mittels USB-Debugging auf ein Handy gestartet.

[[File:MVD-KotlinCode.png|500px]]

https://i.imgur.com/req0VHX.png

https://i.imgur.com/8jGIO3T.png

=== Connection ===
Um sich am Handy mit einem Matter Gerät zu verbinden, braucht man folgende Voraussetzungen:

<li>Android Version - Version >= 8.1</li>
<li>Google Play Service - Version >= 22.36.15</li>
<li>Google Home App - Installiert</li>

==== Steps ====
<li>Zur Überprüfung, ob das Handy bereit ist, Matter Geräte zu verbinden, wird geschaut ob unter Einstellungen -> Google -> Devices and Sharing die Auswahl Matter devices existiert.</li>
<li>Falls nicht, sollte man versuchen die Google Home App neu zu installieren, da beim Download von dieser App gleichzeitig auch die benötigten Dependencies heruntergeladen werden, um sich mit einem Matter Gerät zu verbinden.</li>

[[File:Matter-DevicesAndSharing.png|250px]]
[[File:Matter-Devices.png|250px]]

<li>Sofern dieser Schritt geschafft worden ist, wird im MVD-Controller GUI ein QR-Code generiert.</li>

[[File:MVD-QR.png|500px]]

<li>Auf der App wird auf das + Symbol geklickt und es öffnet sich ein neues Fenster, wo man mit der Kamera den QR-Code scannen kann.</li>

[[File:Matter-Scan.png|250px]]

<li>Beim Verbinden des Gerätes sollte stehen, dass es Matter Credentials erstellt, Commissioned und schlussendlich auch verbunden ist.</li>

[[File:Matter-Connected.png|250px]]

<li></li>
== Security Aspekt ==

Dieses Thema wurde im Rahmen des Wahlfachprojektes 2 vorgestellt. Die Aufgabe bestand darin, mit dem MVD einen Angriff nachzustellen und zu zeigen, dass dieser daher bereits während der Entwicklung erkennt und mitigiert werden könnte. Aufgrund der Neuheit des Standards ist dieser aber noch nicht in der Breite etabliert und daher sind auch noch wenige Vulnerabilities und Exploits bekannt. Daher konnten wir nur eine DoS Attacke ausprobieren und damit den Zugriff auf das MVD verhindern. Eine Differenzierung, ob es dabei zu einem DoS des Gerätes selbst oder der ausführenden Plattform kam, konnte nicht evaluiert werden.

<references>
<ref name="logo">https://commons.wikimedia.org/wiki/File:Matter_logo.jpg</ref>
<ref name="sample-app">https://developers.home.google.com/codelabs/matter-sample-app#1</ref>
<ref name="virtual-device">https://developers.home.google.com/tools/virtual-device</ref>
</references>

[[Category:Documentation]]

Matter

2024-01-27T22:32:20Z

MArcilla:

[[File:Matter_logo.jpg|thumb|Logo of Matter<ref name="logo"/>]]

'''Matter''' ist ein offener Standard, der von der Arbeitsgruppe "Project Connected Home over IP" (kurz CHIP) seit 2019 entwickelt und im Oktober 2022 erstmals publiziert wurde. Er soll die Kommunikation zwischen Geräten diverser Hersteller wie Google, Samsung, Apple und Amazon ermöglichen und damit die Grenzen bestehender Smart-Home Netze erweitern.

== Protokoll ==

Es handelt sich um ein Application-Layer-Protokoll, welches auf Netzwerkprotokolle wie IPv6, Thread und BLE aufsetzt. Um von IP-Netzwerken auf z.B. Thread- oder BLE-basierte Geräte zugreifen zu können werden Bridges benötigt, welche die Netzwerklayer übersetzen.

[[File:Primer-matter-architecture.png|The Matter Stack in the TCP/IP and OSI Model]]

== Matter Virtual Device ==
Das Google Developer Center stellt Resourcen zur Entwicklung von Matter-basierten Geräten wie einer Sample App zum Verbinden von Matter-Geräten <ref name="sample-app" /> oder virtuellen Matter-Geräten <ref name="virtual-device" /> zum Testen der Schnittstellen bereit.

Ein Matter Virtual Device (MVD) ist eine Emulation eines Matter Devices und simuliert das Verhalten eines Gerätes z.B. das Ein-/Ausschalten eines Lichtschalters.

=== Möglichkeiten ===
Das Virtual Device kann man über mehrere Wege bauen und starten. Dazu wurden insgesamt drei Möglichkeiten gefunden:

* Standalone
* Docker Image
* GitHub Repository

Es hat sich herausgestellt, dass das Standalone am Besten geeignet ist, um schnell ein MVD einzurichten. Dazu wird eine Umgebung mit einem 64-bit x86 Prozessor und mindestens Debian 11, Ubuntu 20.04 oder MacOS benötigt.

==== GitHub Repository ====

# git clone https://github.com/project-chip/connectedhomeip
# Initialisieren des Matter-Projektes durch "source scripts/activate.sh"
Diese Variante wurde nicht weiter verfolgt, da das Repository rekursiv aufgelöst wird und das Klonen und Ausführen daher sehr viel Zeit in Anspruch nimmt.

==== Docker Image Repository ====

# docker pull us-docker.pkg.dev/nest-matter/docker-repo/virtual-device-image:latest
Dieser Ansatz lädt ein Docker Image herunter, welches größer als 10GB ist. Entpackt hat es dann mehr als 30GB und ist daher als schneller Ansatz für die Entwicklung mit Matter-Geräten ebenfalls nicht tauglich.

==== Standalone ====
Das Standalone-Matter-Device wurde relativ neu von Google publiziert, lässt sich aber sehr einfach aufsetzen. Durch seine vergleichsweise geringe Größe mit weniger als 70MB ist es einfach herunterzuladen und ist innerhalb weniger Minuten lauffähig.

https://i.imgur.com/Rjqabwb.png

Installationsschritte (Debian/Ubuntu)
# wget https://dl.google.com/mvd/mvd_1.3.0_amd64.deb
# sudo dpkg -i mvd_1.3.0_amd64.deb
# mvd

Es öffnet sich eine GUI, womit man ein MVD erstellen kann.

[[File:MVD-Create.png|500px]]

Beim neuen Fenster kann man einige Einstellungen bezüglich des Gerätes konfigurieren:

# Device Type - Man kann mehrere Arten von Smart Home Geräten simulieren
# Vendor ID - Eindeutige zertifierte ID für den Händler (Mögliche Werte in der Entwicklung: 0xFFF1, 0xFFF2, 0xFFF3 and 0xFFF4)
# Product ID - Eindeutige zertifizierte ID für das Produkt (Mögliche Werte in der Entwicklung: 0x8000 bis 0x801F)
# Discriminator - Im Fall, dass im Netzwerk das gleiche Produkt mehrmals auftritt, kann über den Discriminator unterschieden werden.

=== Controller GUI ===
Um mit dem Matter Device zu kommunizieren, wird eine GUI benötigt. Dazu gibt es wieder zwei Möglichkeiten:

==== Internal GUI über RPC ====
Das Standalone MVD wird mit einer integrierten GUI geliefert, wobei das Gerät auf einem anderen Port (RPC-Port: 33000) angesprochen wird, als den Matter Port (Matter-Port: 5540).
Sobald das MVD erstellt wurde, öffnet sich die Control-UI für das simulierte Gerät.

[[File:MVD-GUI.png|500px]]

==== GUI über Mobile App ====
Das Google Developer Center hat ein CodeLab<ref name="sample-app" /> zur Verfügung gestellt, womit man eine simple Kotlin-App für die Steuerung von Matter Geräten entwickeln kann.
Dazu kann man ein Skeleton herunterladen und das Tutorial begleitet den Entwickler, um etwaige fehlende Code-Stellen zu implementieren, die mit dem Kommentar "// CODELAB:" versehen sind.

Diese App wurde dann mittels USB-Debugging auf ein Handy gestartet.

[[File:MVD-KotlinCode.png|500px]]

https://i.imgur.com/req0VHX.png

https://i.imgur.com/8jGIO3T.png

=== Connection ===
Um sich am Handy mit einem Matter Gerät zu verbinden, braucht man folgende Voraussetzungen:

<li>Android Version - Version >= 8.1</li>
<li>Google Play Service - Version >= 22.36.15</li>
<li>Google Home App - Installiert</li>

==== Steps ====
<li>Zur Überprüfung, ob das Handy bereit ist, Matter Geräte zu verbinden, wird geschaut ob unter Einstellungen -> Google -> Devices and Sharing die Auswahl Matter devices existiert.</li>
<li>Falls nicht, sollte man versuchen die Google Home App neu zu installieren, da beim Download von dieser App gleichzeitig auch die benötigten Dependencies heruntergeladen werden, um sich mit einem Matter Gerät zu verbinden.</li>

[[File:Matter-DevicesAndSharing.png|250px]]
[[File:Matter-Devices.png|250px]]

<li>Sofern dieser Schritt geschafft worden ist, wird im MVD-Controller GUI ein QR-Code generiert.</li>

[[File:MVD-QR.png|500px]]

<li>Auf der App wird auf das + Symbol geklickt und es öffnet sich ein neues Fenster, wo man mit der Kamera den QR-Code scannen kann.</li>

[[File:Matter-Scan.png|250px]]

<li>Beim Verbinden des Gerätes sollte stehen, dass es Matter Credentials erstellt, Commissioned und schlussendlich auch verbunden ist.</li>

[[File:Matter-Connected.png|250px]]

<li></li>
==== Security Aspekt ====

Dieses Thema wurde im Rahmen des Wahlfachprojektes 2 vorgestellt. Die Aufgabe bestand darin, mit dem MVD einen Angriff nachzustellen und zu zeigen, dass dieser daher bereits während der Entwicklung erkennt und mitigiert werden könnte. Aufgrund der Neuheit des Standards ist dieser aber noch nicht in der Breite etabliert und daher sind auch noch wenige Vulnerabilities und Exploits bekannt. Daher konnten wir nur eine DoS Attacke ausprobieren und damit den Zugriff auf das MVD verhindern. Eine Differenzierung, ob es dabei zu einem DoS des Gerätes selbst oder der ausführenden Plattform kam, konnte nicht evaluiert werden.

<references>
<ref name="logo">https://commons.wikimedia.org/wiki/File:Matter_logo.jpg</ref>
<ref name="sample-app">https://developers.home.google.com/codelabs/matter-sample-app#1</ref>
<ref name="virtual-device">https://developers.home.google.com/tools/virtual-device</ref>
</references>

[[Category:Documentation]]

File:MVD-QR.png

2024-01-27T22:21:33Z

MArcilla:

File:Matter-Connected.png

2024-01-27T22:16:54Z

MArcilla:

File:Matter-Scan.png

2024-01-27T22:15:26Z

MArcilla:

File:Matter-Devices.png

2024-01-27T22:12:12Z

MArcilla:

File:Matter-DevicesAndSharing.png

2024-01-27T22:11:28Z

MArcilla:

File:MVD-GUI.png

2024-01-27T22:01:50Z

MArcilla:

File:MVD-Create.png

2024-01-27T22:01:03Z

MArcilla:

File:MVD-KotlinCode.png

2024-01-27T21:59:10Z

MArcilla:

Matter

2024-01-27T21:29:55Z

MArcilla: /* Security Aspekt */

PandwaRF

2024-01-07T08:35:51Z

MArcilla:

[[File:PandwaRF.png]]

== Description ==

PandwaRF is a family of pocket-sized, portable RF analysis tools operating the sub-1
GHz range produced by the Comthings, a French startup focused on the PandwaRF
analysis tool and custom RF penetration testing tools for professionals and law enforcement agencies. <ref>Tania. Home: https://www.comthings.com/</ref>
analysis and re-transmission of RF via an Android device or a Linux PC.

It can be connected to an Android smartphone using BLE or USB, and to Linux using USB.
It is based on the well-known RfCat and Yard Stick One tools with the Texas
Instruments CC1111 RF transceiver <ref>Texas Instruments. instruments guide, https://www.ti.com/product/CC1110-CC1111 ,
2013.</ref>, but with a lot of new features, making
PandwaRF the perfect portable RF analysis tool. Practically, it removes the
‘standard SDR Grind’ of capturing, demodulating, analyzing, modifying and replaying
by hand – replacing it with a simple but powerful interface.

The PandwaRF system consists of two elements: the hardware device and the software controller, either an Android device or a PC.
The hardware is a very capable
device, tailored for beginners and advanced users alike.
Beyond the functionality provided by the Android interface, the PandwaRF can be
easily controlled and customized. No need to risk bricking your device or writing in C,
the PandwaRF can be controlled by JavaScript, directly on the smartphone.
The Rogue Pro was designed for advanced users like pentesters or security professionals and it is specialized on brute forcing wireless devices in order to test their
security.

==General Overview==
PandwaRF is a Radio Frequency hacking tool used to:<ref>https://www.comthings.com/</ref>
===Receive===
<li>Capture any data in ASK/OOK/MSK/2-FSK/GFSK modulation from the frequency range: 300-348 MHz, 391-464 MHz and 782-928 MHz</li>
<li>Transfer the captured data to your smartphone & save/share it
<li>Send the captured data in JSON to your own server for post-processing
<li>Write your own scripts or use a provided one
===Transmit===
<li>Transmit previously captured data or write your own
<li>Transmit data from a smartphone or directly from PandwaRF
<li>Brute force with a predefined transmission pattern (encoders or devices)
<li>Transmit power: +10dBm
===Analyze===
<li>Visualize the frequency used by any device using the PandwaRF built-in Spectrum Analyzer
<li>Directly show the maximum and average RSSI for a specific frequency band

==Technical Overview==
PandwaRF is composed of 2 elements:
<li>PandwaRF HW dongle
<li>PandwaRF Android application

===PandwaRF HW dongle===
The PandwaRF dongle contains<ref> https://pandwarf.com/pandwarf-rogue-pro/ </ref>:
<li>Bluetooth Smart Module ISP130301, based on nRF51
<li>CC1111 Low-Power SoC with Sub-1 GHz RF Transceiver
<li>16 Mbit Flash Memory to save custom RF protocols
<li>Rechargeable battery powered for stand-alone operation
<li>Battery fuel gauge
<li>SMA connector
<li>4 buttons
<li>4 Status LEDs
<li>Debug connectors & GPIOs

==Possible applications==
<li>Receive keyfobs transmission (car, alarm, gate opener, …)
<li>Replay captured transmission from keyfobs
<li>Replay a modified captured transmission
<li>Transmit your own custom payload
<li>Capture RF data and transmit it on another frequency
<li>Brute force wireless devices (alarms, gate openers etc)<ref>https://github.com/ComThings/PandwaRF/wiki</ref>
<li>Spectrum Analyzer
<li>Find the frequency used by a RF device
<li>Reverse engineer unknown protocols
<li>Measure the data rate of a transmission
<li>Check the RF jam-resistance of your own devices
<li>Send captured data to a server for post-processing
<li>Write custom Javascript scenarios
<li>Develop your own Android application

==Hardware Antennas==

In its antenna pack version, PandwaRF is shipped with 3 miniature SMA antennas (315/433/868-915 MHz).

Using the proper antenna is critical to have good RF performance.
Antennas are labelled with the first digit of their frequency band:
<li>3 for 315 MHz,
<li>4 for 433 MHz,
<li>8/9 for 868/915 MHz

===Warning===
PandwaRF is a test equipment for RF systems. It has not been tested for compliance with the regulations governing the transmission of radio signals. You are responsible for using your PandwaRF legally. The intentional jamming of RF signals is ILLEGAL. PandwaRF should only be used for testing the robustness of your own devices.

== Mobile App ==
PandwaRF offers a smartphone app to provide many tools for analysing RF signals:

=== Pairing ===
In order to use the PandwaRF, the device has to be connected to the mobile device via Bluetooth.

[[File:PandwaRFPairing.png|300px]]

=== Spectrum Analyser ===
The spectrum analyser helps measuring the frequency at which a device's signal is exactly operating at. It is also possible to discern the modulation, distortion, noise and bandwidth.

[[File:PandwaRFSpecAnalyse.png|300px]]

=== Rx/Tx Data Transmission ===
This tab is for capturing or transmitting the data of the device to be intercepted. It has two different modes: a beginner-friendly easy mode and hard mode designed for radio experts in order to fine-tune the eavesdropping. The easy mode needs three inputs: Device frequency operation, modulation type, and lastly the data rate.

The operating frequency can be either manually or automatically filled in by the results of the spectrum analyser. The next parameter is the modulation type and it is usually in the device's technical manual. Last but not least, the data rate can be filled in manually or have the rate measured by sending an RF signal.

Once set, the user can start the capture of the transmission and eavesdrop on the message. After having received data it will show in the mobile app as a hex or binary stream.

[[File:PandwaRFRxTx.png|300px]]

=== Brute Force ===
Another tool the app provides is the brute forcing code words on RF devices. With this feature the user can send multiple RF codes to the receiver after having configured the baselines for the code word. In order to start brute-forcing the code word and set-up the analysis tool, the user must gain insight on missing information first such as the RF parameters, codeword settings, etc <ref>https://github.com/ComThings/PandwaRF/wiki</ref>.

[[File:PandwaRFBruteForce.png|300px]]

== Kaiju ==

Kaiju is an online rolling code analyser and generator. It uses the captured payload of the RF signal, processes it, tries to break its encryption on a remote server by ComThings and returns several information including metadata about the victim such as <ref>https://rolling.pandwarf.com</ref>:

<li>Brand/Model</li>
<li>Serial Number</li>
<li>Encryption Scheme</li>

[[File:Kaiju.png]]

=== Rolling Code ===
One of the commonly used techniques when trying to securely gain access on vehicles or garage door openers is a rolling code implementation. This is also known as hopping code. It is an authentication scheme in order for the user to be able to remotely open up their car as an example. Therefore, no physical key is needed for systems using this technique but rather remote keys in the form of remote controls e.g. car key fobs.

In general, this protocol operates on generating a code and having it validated by the receiving device. The transmitter and receiver using this protocol must, however, be synchronised first. The generation of this code happens on the sender side and must be unique. The uniqueness can be guaranteed by having the sender device hold an internal counter and increment it on every code generation.
Every time the user presses the button on their transmission device, it will create a new code. That remote has a unique identifier (UID), which the receiver knows since the first step is to synchronise both devices. The message can be validated by the receiving end as it contains the UID of the remote control. Once accepted, the receiver marks the newly generated code to its list and increments its own counter <ref>https://ieeexplore.ieee.org/document/9851991</ref>.

A good visualization can be found at https://harryli0088.github.io/rolling-code/

==== License required ====
However, to enable the rolling code generation against devices such as garage door openers, a Kaiju license has to be bought from the PandwaRF shop. Once bought, it has to be bound to a Kaiju account and the MAC address of a PandwaRF device. This association cannot be changed unless a request ticket is made to the support e-mail of the PandwaRF team <ref>https://pandwarf.com/product/kaiju-gate-openers-pack-pro-license/</ref>.

== Example: Rolling Code Attack ==
The following section presents an attempt to hack a garage door opener - the Chamberlain ML700EV Comfort <ref>https://stuff.elvis.science/hardware/489</ref> - with the help of the PandwaRF Rogue Pro.
This device consists of a motor, several metal rails for the garage door and two remote controls to operate it. The motor acts as a receiver. The minimal required set-up for the opener to work is to plug in the motor and the remote control can send RF signals to open and close the gate by pressing a button.

[[File:PandwaRFSetup.jpg|500px]]

=== Step 1: Setup RF Parameters ===
In the first step it is important to know what RF parameters the device operates in.
The RF parameters needed to capture in PandwaRF are the following:
<li>Frequency</li>
<li>Modulation</li>
<li>Data rate</li>

For the RF connectivity on the PandwaRF, it can connect two different antennas to its board. One is in the area of 433 MHz while the other operates on around 868 MHz. To find out the operating frequency of the device, there are multiple ways to figure it out. The simplest way to find out the frequency is to look at the vendor's shopping page and the product's technical details. Browsing the manual provided by the packaging is an alternative. Lastly, if the device has an Federal Communications Commission (FCC) ID <ref>https://www.fcc.gov/oet/ea/fccid</ref>, it is possible to search for the necessary data online. The operating frequency has been found inside the manual and it can operate on both the 433 MHz and the 868 MHz bands.

For this example the antenna with the 868 MHz has been screwed in the PandwaRF.

In order to start hacking, the data needs to be recorded and sent to Kaiju.
The capturing of the data can be started in the Rx/Tx tab and have the capture displayed as either a binary or a hex data stream. Before we can start eavesdropping, the two remaining RF parameters (modulation and data rate) have to be found out. The data rate can be simply measured from the current tab whilst the modulation has to be figured out via trial and error.

=== Step 2: Capturing the Data ===
The eavesdrop can now start by initiating the capture in the app and then sending an RF signal from the remote control.

The RF parameters are as follows:
<li>Frequency - 868.225 MHz</li>
<li>Modulation - ASK/OOK</li>
<li>Data rate - 3.999 Bit/s</li>

[[File:PandwaRFRxTx.png|300px]]

[[File:PandwaRFRxTx-Eavesdropped.png|300px]]

=== Step 3: Send to Kaiju ===

After a successful interception, the payload has already been evaluated and it is shown that the captured signal has a pattern that resembles a rolling code implementation. To have Kaiju correctly break through the encryption it is required to change the found Pattern to the Chamberlain Security+ 2.0 (rolling code).

The button on the bottom left will send the selected payload to Kaiju and will automatically generate 10 new rolling codes to use.

[[File:PandwaRF-Patterns.jpg|300px]]
[[File:PandwaRFTransmitToKaiju.png|500px]]

=== Step 4: Use Rolling Codes ===
The payload is sent to the Kaiju servers and they process the data and try to break the encryption. The process behind how it attempt to break it is not stated on the Kaiju website. It cracks the input stream and returns a positive result. The signal has been figured out. Kaiju will automatically generate ten new rolling codes for each payload that was sent to it to be analysed. It is now possible to send these codes from the mobile app to the PandwaRF. The analysis tool will act as an impostor remote control and trigger an action from the actuator.

[[File:PandwaRFTransmitRollingCodes.png|500px]]

=== Evaluation on the Kaiju Website ===
[[File:KaijuHistory.png|500px]]
[[File:KaijuMetadata.png|500px]]
[[File:KaijuRollingCodes.png|500px]]

== References ==

<references />

[[Category:Documentation]]

File:KaijuRollingCodes.png

2024-01-07T08:34:35Z

MArcilla:

File:KaijuMetadata.png

2024-01-07T08:34:27Z

MArcilla:

File:PandwaRF-Patterns.jpg

2024-01-07T08:25:32Z

MArcilla:

File:KaijuHistory.png

2024-01-07T08:03:14Z

MArcilla:

File:PandwaRFTransmitToKaiju.png

2024-01-07T08:01:00Z

MArcilla:

File:Kaiju.png

2024-01-07T07:57:19Z

MArcilla:

File:PandwaRFPairing.png

2024-01-07T07:47:36Z

MArcilla:

File:PandwaRFSetup.jpg

2024-01-07T07:38:12Z

MArcilla:

File:PandwaRFTransmitRollingCodes.png

2024-01-07T07:37:22Z

MArcilla:

File:PandwaRFRxTx-Eavesdropped.png

2024-01-07T07:36:40Z

MArcilla:

File:PandwaRFRxTx.png

2024-01-07T07:36:19Z

MArcilla:

File:PandwaRFBruteForce.png

2024-01-07T07:34:18Z

MArcilla:

File:PandwaRFSpecAnalyse.png

2024-01-07T07:33:35Z

MArcilla:

File:Unittest-OSCORE.png

2023-07-04T19:08:07Z

MArcilla: MArcilla uploaded a new version of File:Unittest-OSCORE.png

File:Unittest-OSCORE.png

2023-07-04T19:06:53Z

MArcilla: MArcilla uploaded a new version of File:Unittest-OSCORE.png

File:Unittest-OSCORE.png

2023-07-04T19:03:55Z

MArcilla: MArcilla uploaded a new version of File:Unittest-OSCORE.png

CoMatrix: OSCORE

2023-07-04T07:31:00Z

MArcilla: /* Gateway */

== Summary ==

This documentation describes the usage of an application-layer protocol OSCORE to provide end-to-end protection between the [https://comatrix.eu/setup/architecture_and_testbed CoMatrix Gateway and CoMatrix Client].

== Requirements ==

* Operating system:
** Ubuntu 22.04 (Gateway)
** RIOT OS (Client)
* See [[#Used Hardware]]

In order to complete these steps, you must set up the [https://comatrix.eu/setup/ CoMatrix project] before.

== Description ==

OSCORE is a security protocol designed to provide end-to-end protection between endpoints communicating using CoAP.

A key exchange protocol does not exist OSCORE and the keys are pre-shared between Gateway and Client. However, there is ongoing work with key exchanges such as EDHOC or [https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-11 ACE-OSCORE]

== Gateway ==

The Python library aiocoap provided the OSCORE functionality and was implemented in order for the gateway to talk in OSCORE

=== Imports ===

Following imports were added

from aiocoap.oscore_sitewrapper import OscoreSiteWrapper
from aiocoap.credentials import CredentialsMap
from plugtest_common import *
from aiocoap.cli.common import server_context_from_arguments, add_server_arguments

* The plugtest_common import was extracted from the aiocoap OSCORE plugtest and provides verification for external AADs and returning the security context.

=== Main ===

When starting the gateway, new parameters have been added to list the directory where the pre-shared secrets are held and sequence numbers will be saved. These sequence numbers are necessary for replay protection.

parser.add_argument("contextdir", help="Directory name where to persist sequence numbers and the location of the secrets", type=Path)

// Necessary to add these arguments provided by the aiocoap library in order for the server to start correctly. More info under aiocoap/cli/common.py
add_server_arguments(parser)

The context directory may contain two files:
* secrets.json
* settings.json
As per implementation it is sufficient to only have one of these files in the directory.

The format of the file is the following JSON:
{
"sender-id_hex": "01",
"recipient-id_ascii": "file",
"secret_ascii": "Correct Horse Battery Staple"
}

Important properties are:
* sender-id
* recipient-id
* secret

These three properties must be appended with either _hex or _ascii and have the values according to the suffix.

Assume that the file above was for the server and for our client we would need the following file:
{
"sender-id_ascii": "file",
"recipient-id_hex": "01",
"secret_ascii": "Correct Horse Battery Staple"
}

Notice how sender-id and recipient-id had to be swapped.
With these two secret files it is now possible to start a gateway and a client each using a different JSON file with the ids flipped.

For further information see [https://aiocoap.readthedocs.io/en/latest/stateofoscore.html#oscore-credentials aiocoap-OSCORE]

Loading these in the code was done in the following way - For testing purposes there were two pairs of credentials a / b and c / d whereas the first one is used for the test client and the latter for the gateway:

// Loading the pre-shared secrets
server_credentials = CredentialsMap()
// the first parameter states the name of the context in this case it's b but can be named in any way and the second parameter is the path to the folder e.g. the file would be located in /contextdir/b/settings.json
server_credentials[':b'] = get_security_context('b', args.contextdir / "b")
server_credentials[':d'] = get_security_context('d', args.contextdir / "d")

To enable OSCORE for the server now the following code was added/adjusted:
// root is the variable for the site
// Enable the site to talK OSCORE with the credentials loaded from before
root = OscoreSiteWrapper(root, server_credentials)
args.bind = bind
// Now we create a server context with arguments added
asyncio.Task(server_context_from_arguments(root, args))

'''USAGE:''' ./comatrix_gateway.py contextdir

[[File:CoMatrix-Gateway-OSCORE.png]]

To test if the gateway actually talks in OSCORE the plugtest-client from the aiocoap library was adjusted to meet our needs for comatrix.

'''USAGE:''' ./unit-tests.py host contextdir

[[File:Unittest-OSCORE.png]]

=== Wireshark Capture ===

The Wireshark Capture can be downloaded here:
[[Media:OSCORE-wireshark-capture.zip]]

[[File:OSCORE-wireshark.png]]

== Client ==
// Await docs

== Used Hardware ==

* Raspberry Pi 3B+ Model (CoMatrix Gateway)
* OpenLabs 802.15.4. radio module
* SAMR21-xpro (CoMatrix Client)
* (optional) Raspberry Pi 4 (Matrix Homeserver)

== References ==

* https://comatrix.eu
* https://aiocoap.readthedocs.io
* https://github.com/chrysn/liboscore

[[Category:Documentation]]

CoMatrix: OSCORE

2023-07-04T07:30:22Z

MArcilla: /* Wireshark Capture */

== Summary ==

This documentation describes the usage of an application-layer protocol OSCORE to provide end-to-end protection between the [https://comatrix.eu/setup/architecture_and_testbed CoMatrix Gateway and CoMatrix Client].

== Requirements ==

* Operating system:
** Ubuntu 22.04 (Gateway)
** RIOT OS (Client)
* See [[#Used Hardware]]

In order to complete these steps, you must set up the [https://comatrix.eu/setup/ CoMatrix project] before.

== Description ==

OSCORE is a security protocol designed to provide end-to-end protection between endpoints communicating using CoAP.

A key exchange protocol does not exist OSCORE and the keys are pre-shared between Gateway and Client. However, there is ongoing work with key exchanges such as EDHOC or [https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-11 ACE-OSCORE]

== Gateway ==

The Python library aiocoap provided the OSCORE functionality and was implemented in order for the gateway to talk in OSCORE

=== Imports ===

Following imports were added

from aiocoap.oscore_sitewrapper import OscoreSiteWrapper
from aiocoap.credentials import CredentialsMap
from plugtest_common import *
from aiocoap.cli.common import server_context_from_arguments, add_server_arguments

* The plugtest_common import was extracted from the aiocoap OSCORE plugtest and provides verification for external AADs and returning the security context.

=== Main ===

When starting the gateway, new parameters have been added to list the directory where the pre-shared secrets are held and sequence numbers will be saved. These sequence numbers are necessary for replay protection.

parser.add_argument("contextdir", help="Directory name where to persist sequence numbers and the location of the secrets", type=Path)

// Necessary to add these arguments provided by the aiocoap library in order for the server to start correctly. More info under aiocoap/cli/common.py
add_server_arguments(parser)

The context directory may contain two files:
* secrets.json
* settings.json
As per implementation it is sufficient to only have one of these files in the directory.

The format of the file is the following JSON:
{
"sender-id_hex": "01",
"recipient-id_ascii": "file",
"secret_ascii": "Correct Horse Battery Staple"
}

Important properties are:
* sender-id
* recipient-id
* secret

These three properties must be appended with either _hex or _ascii and have the values according to the suffix.

Assume that the file above was for the server and for our client we would need the following file:
{
"sender-id_ascii": "file",
"recipient-id_hex": "01",
"secret_ascii": "Correct Horse Battery Staple"
}

Notice how sender-id and recipient-id had to be swapped.
With these two secret files it is now possible to start a gateway and a client each using a different JSON file with the ids flipped.

For further information see [https://aiocoap.readthedocs.io/en/latest/stateofoscore.html#oscore-credentials aiocoap-OSCORE]

Loading these in the code was done in the following way - For testing purposes there were two pairs of credentials a / b and c / d whereas the first one is used for the test client and the latter for the gateway:

// Loading the pre-shared secrets
server_credentials = CredentialsMap()
// the first parameter states the name of the context in this case it's b but can be named in any way and the second parameter is the path to the folder e.g. the file would be located in /contextdir/b/settings.json
server_credentials[':b'] = get_security_context('b', args.contextdir / "b")
server_credentials[':d'] = get_security_context('d', args.contextdir / "d")

To enable OSCORE for the server now the following code was added/adjusted:
// root is the variable for the site
// Enable the site to talK OSCORE with the credentials loaded from before
root = OscoreSiteWrapper(root, server_credentials)
args.bind = bind
// Now we create a server context with arguments added
asyncio.Task(server_context_from_arguments(root, args))

'''USAGE:''' ./comatrix_gateway.py contextdir

// TODO How to add picture in

To test if the gateway actually talks in OSCORE the plugtest-client from the aiocoap library was adjusted to meet our needs for comatrix.

'''USAGE:''' ./unit-tests.py host contextdir

// TODO Picture

=== Wireshark Capture ===

The Wireshark Capture can be downloaded here:
[[Media:OSCORE-wireshark-capture.zip]]

[[File:OSCORE-wireshark.png]]

== Client ==
// Await docs

== Used Hardware ==

* Raspberry Pi 3B+ Model (CoMatrix Gateway)
* OpenLabs 802.15.4. radio module
* SAMR21-xpro (CoMatrix Client)
* (optional) Raspberry Pi 4 (Matrix Homeserver)

== References ==

* https://comatrix.eu
* https://aiocoap.readthedocs.io
* https://github.com/chrysn/liboscore

[[Category:Documentation]]

File:OSCORE-wireshark-capture.zip

2023-07-04T07:29:07Z

MArcilla:

File:OSCORE-wireshark.png

2023-07-04T07:16:38Z

MArcilla:

File:Unittest-OSCORE.png

2023-07-04T07:04:35Z

MArcilla:

File:CoMatrix-Gateway-OSCORE.png

2023-07-04T07:02:18Z

MArcilla:

CoMatrix: OSCORE

2023-07-04T06:58:23Z

MArcilla: /* Gateway */

== Summary ==

This documentation describes the usage of an application-layer protocol OSCORE to provide end-to-end protection between the [https://comatrix.eu/setup/architecture_and_testbed CoMatrix Gateway and CoMatrix Client].

== Requirements ==

* Operating system:
** Ubuntu 22.04 (Gateway)
** RIOT OS (Client)
* See [[#Used Hardware]]

In order to complete these steps, you must set up the [https://comatrix.eu/setup/ CoMatrix project] before.

== Description ==

OSCORE is a security protocol designed to provide end-to-end protection between endpoints communicating using CoAP.

A key exchange protocol does not exist OSCORE and the keys are pre-shared between Gateway and Client. However, there is ongoing work with key exchanges such as EDHOC or [https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-11 ACE-OSCORE]

== Gateway ==

The Python library aiocoap provided the OSCORE functionality and was implemented in order for the gateway to talk in OSCORE

=== Imports ===

Following imports were added

from aiocoap.oscore_sitewrapper import OscoreSiteWrapper
from aiocoap.credentials import CredentialsMap
from plugtest_common import *
from aiocoap.cli.common import server_context_from_arguments, add_server_arguments

* The plugtest_common import was extracted from the aiocoap OSCORE plugtest and provides verification for external AADs and returning the security context.

=== Main ===

When starting the gateway, new parameters have been added to list the directory where the pre-shared secrets are held and sequence numbers will be saved. These sequence numbers are necessary for replay protection.

parser.add_argument("contextdir", help="Directory name where to persist sequence numbers and the location of the secrets", type=Path)

// Necessary to add these arguments provided by the aiocoap library in order for the server to start correctly. More info under aiocoap/cli/common.py
add_server_arguments(parser)

The context directory may contain two files:
* secrets.json
* settings.json
As per implementation it is sufficient to only have one of these files in the directory.

The format of the file is the following JSON:
{
"sender-id_hex": "01",
"recipient-id_ascii": "file",
"secret_ascii": "Correct Horse Battery Staple"
}

Important properties are:
* sender-id
* recipient-id
* secret

These three properties must be appended with either _hex or _ascii and have the values according to the suffix.

Assume that the file above was for the server and for our client we would need the following file:
{
"sender-id_ascii": "file",
"recipient-id_hex": "01",
"secret_ascii": "Correct Horse Battery Staple"
}

Notice how sender-id and recipient-id had to be swapped.
With these two secret files it is now possible to start a gateway and a client each using a different JSON file with the ids flipped.

For further information see [https://aiocoap.readthedocs.io/en/latest/stateofoscore.html#oscore-credentials aiocoap-OSCORE]

Loading these in the code was done in the following way - For testing purposes there were two pairs of credentials a / b and c / d whereas the first one is used for the test client and the latter for the gateway:

// Loading the pre-shared secrets
server_credentials = CredentialsMap()
// the first parameter states the name of the context in this case it's b but can be named in any way and the second parameter is the path to the folder e.g. the file would be located in /contextdir/b/settings.json
server_credentials[':b'] = get_security_context('b', args.contextdir / "b")
server_credentials[':d'] = get_security_context('d', args.contextdir / "d")

To enable OSCORE for the server now the following code was added/adjusted:
// root is the variable for the site
// Enable the site to talK OSCORE with the credentials loaded from before
root = OscoreSiteWrapper(root, server_credentials)
args.bind = bind
// Now we create a server context with arguments added
asyncio.Task(server_context_from_arguments(root, args))

'''USAGE:''' ./comatrix_gateway.py contextdir

// TODO How to add picture in

To test if the gateway actually talks in OSCORE the plugtest-client from the aiocoap library was adjusted to meet our needs for comatrix.

'''USAGE:''' ./unit-tests.py host contextdir

// TODO Picture

=== Wireshark Capture ===

// TODO How to add a picture

== Client ==
// Await docs

== Used Hardware ==

* Raspberry Pi 3B+ Model (CoMatrix Gateway)
* OpenLabs 802.15.4. radio module
* SAMR21-xpro (CoMatrix Client)
* (optional) Raspberry Pi 4 (Matrix Homeserver)

== References ==

* https://comatrix.eu
* https://aiocoap.readthedocs.io
* https://github.com/chrysn/liboscore

[[Category:Documentation]]

CoMatrix: OSCORE

2023-07-04T06:57:51Z

MArcilla: /* Description */

== Summary ==

This documentation describes the usage of an application-layer protocol OSCORE to provide end-to-end protection between the [https://comatrix.eu/setup/architecture_and_testbed CoMatrix Gateway and CoMatrix Client].

== Requirements ==

* Operating system:
** Ubuntu 22.04 (Gateway)
** RIOT OS (Client)
* See [[#Used Hardware]]

In order to complete these steps, you must set up the [https://comatrix.eu/setup/ CoMatrix project] before.

== Description ==

OSCORE is a security protocol designed to provide end-to-end protection between endpoints communicating using CoAP.

A key exchange protocol does not exist OSCORE and the keys are pre-shared between Gateway and Client. However, there is ongoing work with key exchanges such as EDHOC or [https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-11 ACE-OSCORE]

== Gateway ==

The Python library aiocoap provided the OSCORE functionality and was implemented in order for the gateway to talk in OSCORE

=== Imports ===

Following imports were added

from aiocoap.oscore_sitewrapper import OscoreSiteWrapper
from aiocoap.credentials import CredentialsMap
from plugtest_common import *
from aiocoap.cli.common import server_context_from_arguments, add_server_arguments

* The plugtest_common import was extracted from the aiocoap OSCORE plugtest and provides verification for external AADs and returning the security context.

=== Main ===

When starting the gateway, new parameters have been added to list the directory where the pre-shared secrets are held and sequence numbers will be saved. These sequence numbers are necessary for replay protection.

parser.add_argument("contextdir", help="Directory name where to persist sequence numbers and the location of the secrets", type=Path)

// Necessary to add these arguments provided by the aiocoap library in order for the server to start correctly. More info under aiocoap/cli/common.py
add_server_arguments(parser)

The context directory may contain two files:
* secrets.json
* settings.json
As per implementation it is sufficient to only have one of these files in the directory.

The format of the file is the following JSON:
{
"sender-id_hex": "01",
"recipient-id_ascii": "file",
"secret_ascii": "Correct Horse Battery Staple"
}

Important properties are:
* sender-id
* recipient-id
* secret

These three properties must be appended with either _hex or _ascii and have the values according to the suffix.

Assume that the file above was for the server and for our client we would need the following file:
{
"sender-id_ascii": "file",
"recipient-id_hex": "01",
"secret_ascii": "Correct Horse Battery Staple"
}

Notice how sender-id and recipient-id had to be swapped.
With these two secret files it is now possible to start a gateway and a client each using a different JSON file with the ids flipped.

For further information see [https://aiocoap.readthedocs.io/en/latest/stateofoscore.html#oscore-credentials aiocoap-OSCORE]

Loading these in the code was done in the following way - For testing purposes there were two pairs of credentials a / b and c / d whereas the first one is used for the test client and the latter for the gateway:

// Loading the pre-shared secrets
server_credentials = CredentialsMap()
// the first parameter states the name of the context in this case it's b but can be named in any way and the second parameter is the path to the folder e.g. the file would be located in /contextdir/b/settings.json
server_credentials[':b'] = get_security_context('b', args.contextdir / "b")
server_credentials[':d'] = get_security_context('d', args.contextdir / "d")

To enable OSCORE for the server now the following code was added/adjusted:
// root is the variable for the site
// Enable the site to talK OSCORE with the credentials loaded from before
root = OscoreSiteWrapper(root, server_credentials)
args.bind = bind
// Now we create a server context with arguments added
asyncio.Task(server_context_from_arguments(root, args))

'''USAGE:''' ./comatrix_gateway.py contextdir

// TODO How to add picture in

To test if the gateway actually talks in OSCORE the plugtest-client from the aiocoap library was adjusted to meet our needs for comatrix.

'''USAGE:''' ./unit-tests.py host contextdir

// TODO Picture

== Client ==
// Await docs

== Used Hardware ==

* Raspberry Pi 3B+ Model (CoMatrix Gateway)
* OpenLabs 802.15.4. radio module
* SAMR21-xpro (CoMatrix Client)
* (optional) Raspberry Pi 4 (Matrix Homeserver)

== References ==

* https://comatrix.eu
* https://aiocoap.readthedocs.io
* https://github.com/chrysn/liboscore

[[Category:Documentation]]

CoMatrix: OSCORE

2023-07-04T06:55:44Z

MArcilla: /* Used Hardware */

== Summary ==

This documentation describes the usage of an application-layer protocol OSCORE to provide end-to-end protection between the [https://comatrix.eu/setup/architecture_and_testbed CoMatrix Gateway and CoMatrix Client].

== Requirements ==

* Operating system:
** Ubuntu 22.04 (Gateway)
** RIOT OS (Client)
* See [[#Used Hardware]]

In order to complete these steps, you must set up the [https://comatrix.eu/setup/ CoMatrix project] before.

== Description ==

OSCORE is a security protocol designed to provide end-to-end protection between endpoints communicating using CoAP.

A key exchange protocol does not exist OSCORE and the keys are pre-shared between Gateway and Client. However, there is ongoing work with key exchanges such as EDHOC or [https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-11 ACE-OSCORE]

=== Gateway ===

The Python library aiocoap provided the OSCORE functionality and was implemented in order for the gateway to talk in OSCORE

==== Imports ====

Following imports were added

from aiocoap.oscore_sitewrapper import OscoreSiteWrapper
from aiocoap.credentials import CredentialsMap
from plugtest_common import *
from aiocoap.cli.common import server_context_from_arguments, add_server_arguments

* The plugtest_common import was extracted from the aiocoap OSCORE plugtest and provides verification for external AADs and returning the security context.

==== Main ====

When starting the gateway, new parameters have been added to list the directory where the pre-shared secrets are held and sequence numbers will be saved. These sequence numbers are necessary for replay protection.

parser.add_argument("contextdir", help="Directory name where to persist sequence numbers and the location of the secrets", type=Path)

// Necessary to add these arguments provided by the aiocoap library in order for the server to start correctly. More info under aiocoap/cli/common.py
add_server_arguments(parser)

The context directory may contain two files:
* secrets.json
* settings.json
As per implementation it is sufficient to only have one of these files in the directory.

The format of the file is the following JSON:
{
"sender-id_hex": "01",
"recipient-id_ascii": "file",
"secret_ascii": "Correct Horse Battery Staple"
}

Important properties are:
* sender-id
* recipient-id
* secret

These three properties must be appended with either _hex or _ascii and have the values according to the suffix.

Assume that the file above was for the server and for our client we would need the following file:
{
"sender-id_ascii": "file",
"recipient-id_hex": "01",
"secret_ascii": "Correct Horse Battery Staple"
}

Notice how sender-id and recipient-id had to be swapped.
With these two secret files it is now possible to start a gateway and a client each using a different JSON file with the ids flipped.

For further information see [https://aiocoap.readthedocs.io/en/latest/stateofoscore.html#oscore-credentials aiocoap-OSCORE]

Loading these in the code was done in the following way - For testing purposes there were two pairs of credentials a / b and c / d whereas the first one is used for the test client and the latter for the gateway:

// Loading the pre-shared secrets
server_credentials = CredentialsMap()
// the first parameter states the name of the context in this case it's b but can be named in any way and the second parameter is the path to the folder e.g. the file would be located in /contextdir/b/settings.json
server_credentials[':b'] = get_security_context('b', args.contextdir / "b")
server_credentials[':d'] = get_security_context('d', args.contextdir / "d")

To enable OSCORE for the server now the following code was added/adjusted:
// root is the variable for the site
// Enable the site to talK OSCORE with the credentials loaded from before
root = OscoreSiteWrapper(root, server_credentials)
args.bind = bind
// Now we create a server context with arguments added
asyncio.Task(server_context_from_arguments(root, args))

'''USAGE:''' ./comatrix_gateway.py contextdir

// TODO How to add picture in

To test if the gateway actually talks in OSCORE the plugtest-client from the aiocoap library was adjusted to meet our needs for comatrix.

'''USAGE:''' ./unit-tests.py host contextdir

// TODO Picture

== Client ==
// Await docs

== Used Hardware ==

* Raspberry Pi 3B+ Model (CoMatrix Gateway)
* OpenLabs 802.15.4. radio module
* SAMR21-xpro (CoMatrix Client)
* (optional) Raspberry Pi 4 (Matrix Homeserver)

== References ==

* https://comatrix.eu
* https://aiocoap.readthedocs.io
* https://github.com/chrysn/liboscore

[[Category:Documentation]]

CoMatrix: OSCORE

2023-07-04T06:55:20Z

MArcilla: /* Requirements */

== Summary ==

This documentation describes the usage of an application-layer protocol OSCORE to provide end-to-end protection between the [https://comatrix.eu/setup/architecture_and_testbed CoMatrix Gateway and CoMatrix Client].

== Requirements ==

* Operating system:
** Ubuntu 22.04 (Gateway)
** RIOT OS (Client)
* See [[#Used Hardware]]

In order to complete these steps, you must set up the [https://comatrix.eu/setup/ CoMatrix project] before.

== Description ==

OSCORE is a security protocol designed to provide end-to-end protection between endpoints communicating using CoAP.

A key exchange protocol does not exist OSCORE and the keys are pre-shared between Gateway and Client. However, there is ongoing work with key exchanges such as EDHOC or [https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-11 ACE-OSCORE]

=== Gateway ===

The Python library aiocoap provided the OSCORE functionality and was implemented in order for the gateway to talk in OSCORE

==== Imports ====

Following imports were added

from aiocoap.oscore_sitewrapper import OscoreSiteWrapper
from aiocoap.credentials import CredentialsMap
from plugtest_common import *
from aiocoap.cli.common import server_context_from_arguments, add_server_arguments

* The plugtest_common import was extracted from the aiocoap OSCORE plugtest and provides verification for external AADs and returning the security context.

==== Main ====

When starting the gateway, new parameters have been added to list the directory where the pre-shared secrets are held and sequence numbers will be saved. These sequence numbers are necessary for replay protection.

parser.add_argument("contextdir", help="Directory name where to persist sequence numbers and the location of the secrets", type=Path)

// Necessary to add these arguments provided by the aiocoap library in order for the server to start correctly. More info under aiocoap/cli/common.py
add_server_arguments(parser)

The context directory may contain two files:
* secrets.json
* settings.json
As per implementation it is sufficient to only have one of these files in the directory.

The format of the file is the following JSON:
{
"sender-id_hex": "01",
"recipient-id_ascii": "file",
"secret_ascii": "Correct Horse Battery Staple"
}

Important properties are:
* sender-id
* recipient-id
* secret

These three properties must be appended with either _hex or _ascii and have the values according to the suffix.

Assume that the file above was for the server and for our client we would need the following file:
{
"sender-id_ascii": "file",
"recipient-id_hex": "01",
"secret_ascii": "Correct Horse Battery Staple"
}

Notice how sender-id and recipient-id had to be swapped.
With these two secret files it is now possible to start a gateway and a client each using a different JSON file with the ids flipped.

For further information see [https://aiocoap.readthedocs.io/en/latest/stateofoscore.html#oscore-credentials aiocoap-OSCORE]

Loading these in the code was done in the following way - For testing purposes there were two pairs of credentials a / b and c / d whereas the first one is used for the test client and the latter for the gateway:

// Loading the pre-shared secrets
server_credentials = CredentialsMap()
// the first parameter states the name of the context in this case it's b but can be named in any way and the second parameter is the path to the folder e.g. the file would be located in /contextdir/b/settings.json
server_credentials[':b'] = get_security_context('b', args.contextdir / "b")
server_credentials[':d'] = get_security_context('d', args.contextdir / "d")

To enable OSCORE for the server now the following code was added/adjusted:
// root is the variable for the site
// Enable the site to talK OSCORE with the credentials loaded from before
root = OscoreSiteWrapper(root, server_credentials)
args.bind = bind
// Now we create a server context with arguments added
asyncio.Task(server_context_from_arguments(root, args))

'''USAGE:''' ./comatrix_gateway.py contextdir

// TODO How to add picture in

To test if the gateway actually talks in OSCORE the plugtest-client from the aiocoap library was adjusted to meet our needs for comatrix.

'''USAGE:''' ./unit-tests.py host contextdir

// TODO Picture

== Client ==
// Await docs

== Used Hardware ==

* Raspberry Pi 3B+ Model (CoMatrix Gateway)
* OpenLabs 802.15.4. radio module
* SAMR21-xpro (CoMatrix Client)
* Raspberry Pi 4 (Matrix Homeserver)

== References ==

* https://comatrix.eu
* https://aiocoap.readthedocs.io
* https://github.com/chrysn/liboscore

[[Category:Documentation]]

CoMatrix: OSCORE

2023-07-04T06:55:02Z

MArcilla: /* Requirements */

== Summary ==

This documentation describes the usage of an application-layer protocol OSCORE to provide end-to-end protection between the [https://comatrix.eu/setup/architecture_and_testbed CoMatrix Gateway and CoMatrix Client].

== Requirements ==

* Operating system:
** Ubuntu 22.04 (Gateway)
** RIOT OS (Client)
* See [#Used Hardware]

In order to complete these steps, you must set up the [https://comatrix.eu/setup/ CoMatrix project] before.

== Description ==

OSCORE is a security protocol designed to provide end-to-end protection between endpoints communicating using CoAP.

A key exchange protocol does not exist OSCORE and the keys are pre-shared between Gateway and Client. However, there is ongoing work with key exchanges such as EDHOC or [https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-11 ACE-OSCORE]

=== Gateway ===

The Python library aiocoap provided the OSCORE functionality and was implemented in order for the gateway to talk in OSCORE

==== Imports ====

Following imports were added

from aiocoap.oscore_sitewrapper import OscoreSiteWrapper
from aiocoap.credentials import CredentialsMap
from plugtest_common import *
from aiocoap.cli.common import server_context_from_arguments, add_server_arguments

* The plugtest_common import was extracted from the aiocoap OSCORE plugtest and provides verification for external AADs and returning the security context.

==== Main ====

When starting the gateway, new parameters have been added to list the directory where the pre-shared secrets are held and sequence numbers will be saved. These sequence numbers are necessary for replay protection.

parser.add_argument("contextdir", help="Directory name where to persist sequence numbers and the location of the secrets", type=Path)

// Necessary to add these arguments provided by the aiocoap library in order for the server to start correctly. More info under aiocoap/cli/common.py
add_server_arguments(parser)

The context directory may contain two files:
* secrets.json
* settings.json
As per implementation it is sufficient to only have one of these files in the directory.

The format of the file is the following JSON:
{
"sender-id_hex": "01",
"recipient-id_ascii": "file",
"secret_ascii": "Correct Horse Battery Staple"
}

Important properties are:
* sender-id
* recipient-id
* secret

These three properties must be appended with either _hex or _ascii and have the values according to the suffix.

Assume that the file above was for the server and for our client we would need the following file:
{
"sender-id_ascii": "file",
"recipient-id_hex": "01",
"secret_ascii": "Correct Horse Battery Staple"
}

Notice how sender-id and recipient-id had to be swapped.
With these two secret files it is now possible to start a gateway and a client each using a different JSON file with the ids flipped.

For further information see [https://aiocoap.readthedocs.io/en/latest/stateofoscore.html#oscore-credentials aiocoap-OSCORE]

Loading these in the code was done in the following way - For testing purposes there were two pairs of credentials a / b and c / d whereas the first one is used for the test client and the latter for the gateway:

// Loading the pre-shared secrets
server_credentials = CredentialsMap()
// the first parameter states the name of the context in this case it's b but can be named in any way and the second parameter is the path to the folder e.g. the file would be located in /contextdir/b/settings.json
server_credentials[':b'] = get_security_context('b', args.contextdir / "b")
server_credentials[':d'] = get_security_context('d', args.contextdir / "d")

To enable OSCORE for the server now the following code was added/adjusted:
// root is the variable for the site
// Enable the site to talK OSCORE with the credentials loaded from before
root = OscoreSiteWrapper(root, server_credentials)
args.bind = bind
// Now we create a server context with arguments added
asyncio.Task(server_context_from_arguments(root, args))

'''USAGE:''' ./comatrix_gateway.py contextdir

// TODO How to add picture in

To test if the gateway actually talks in OSCORE the plugtest-client from the aiocoap library was adjusted to meet our needs for comatrix.

'''USAGE:''' ./unit-tests.py host contextdir

// TODO Picture

== Client ==
// Await docs

== Used Hardware ==

* Raspberry Pi 3B+ Model (CoMatrix Gateway)
* OpenLabs 802.15.4. radio module
* SAMR21-xpro (CoMatrix Client)
* Raspberry Pi 4 (Matrix Homeserver)

== References ==

* https://comatrix.eu
* https://aiocoap.readthedocs.io
* https://github.com/chrysn/liboscore

[[Category:Documentation]]

CoMatrix: OSCORE

2023-07-04T06:54:44Z

MArcilla: /* Requirements */

== Summary ==

This documentation describes the usage of an application-layer protocol OSCORE to provide end-to-end protection between the [https://comatrix.eu/setup/architecture_and_testbed CoMatrix Gateway and CoMatrix Client].

== Requirements ==

* Operating system:
** Ubuntu 22.04 (Gateway)
** RIOT OS (Client)
* Hardware

In order to complete these steps, you must set up the [https://comatrix.eu/setup/ CoMatrix project] before.

== Description ==

OSCORE is a security protocol designed to provide end-to-end protection between endpoints communicating using CoAP.

A key exchange protocol does not exist OSCORE and the keys are pre-shared between Gateway and Client. However, there is ongoing work with key exchanges such as EDHOC or [https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-11 ACE-OSCORE]

=== Gateway ===

The Python library aiocoap provided the OSCORE functionality and was implemented in order for the gateway to talk in OSCORE

==== Imports ====

Following imports were added

from aiocoap.oscore_sitewrapper import OscoreSiteWrapper
from aiocoap.credentials import CredentialsMap
from plugtest_common import *
from aiocoap.cli.common import server_context_from_arguments, add_server_arguments

* The plugtest_common import was extracted from the aiocoap OSCORE plugtest and provides verification for external AADs and returning the security context.

==== Main ====

When starting the gateway, new parameters have been added to list the directory where the pre-shared secrets are held and sequence numbers will be saved. These sequence numbers are necessary for replay protection.

parser.add_argument("contextdir", help="Directory name where to persist sequence numbers and the location of the secrets", type=Path)

// Necessary to add these arguments provided by the aiocoap library in order for the server to start correctly. More info under aiocoap/cli/common.py
add_server_arguments(parser)

The context directory may contain two files:
* secrets.json
* settings.json
As per implementation it is sufficient to only have one of these files in the directory.

The format of the file is the following JSON:
{
"sender-id_hex": "01",
"recipient-id_ascii": "file",
"secret_ascii": "Correct Horse Battery Staple"
}

Important properties are:
* sender-id
* recipient-id
* secret

These three properties must be appended with either _hex or _ascii and have the values according to the suffix.

Assume that the file above was for the server and for our client we would need the following file:
{
"sender-id_ascii": "file",
"recipient-id_hex": "01",
"secret_ascii": "Correct Horse Battery Staple"
}

Notice how sender-id and recipient-id had to be swapped.
With these two secret files it is now possible to start a gateway and a client each using a different JSON file with the ids flipped.

For further information see [https://aiocoap.readthedocs.io/en/latest/stateofoscore.html#oscore-credentials aiocoap-OSCORE]

Loading these in the code was done in the following way - For testing purposes there were two pairs of credentials a / b and c / d whereas the first one is used for the test client and the latter for the gateway:

// Loading the pre-shared secrets
server_credentials = CredentialsMap()
// the first parameter states the name of the context in this case it's b but can be named in any way and the second parameter is the path to the folder e.g. the file would be located in /contextdir/b/settings.json
server_credentials[':b'] = get_security_context('b', args.contextdir / "b")
server_credentials[':d'] = get_security_context('d', args.contextdir / "d")

To enable OSCORE for the server now the following code was added/adjusted:
// root is the variable for the site
// Enable the site to talK OSCORE with the credentials loaded from before
root = OscoreSiteWrapper(root, server_credentials)
args.bind = bind
// Now we create a server context with arguments added
asyncio.Task(server_context_from_arguments(root, args))

'''USAGE:''' ./comatrix_gateway.py contextdir

// TODO How to add picture in

To test if the gateway actually talks in OSCORE the plugtest-client from the aiocoap library was adjusted to meet our needs for comatrix.

'''USAGE:''' ./unit-tests.py host contextdir

// TODO Picture

== Client ==
// Await docs

== Used Hardware ==

* Raspberry Pi 3B+ Model (CoMatrix Gateway)
* OpenLabs 802.15.4. radio module
* SAMR21-xpro (CoMatrix Client)
* Raspberry Pi 4 (Matrix Homeserver)

== References ==

* https://comatrix.eu
* https://aiocoap.readthedocs.io
* https://github.com/chrysn/liboscore

[[Category:Documentation]]

CoMatrix: OSCORE

2023-07-04T06:54:28Z

MArcilla: /* Description */

== Summary ==

This documentation describes the usage of an application-layer protocol OSCORE to provide end-to-end protection between the [https://comatrix.eu/setup/architecture_and_testbed CoMatrix Gateway and CoMatrix Client].

== Requirements ==

* Operating system:
** Ubuntu 22.04 (Gateway)
** RIOT OS (Client)
* Hardware

In order to complete these steps, you must set up the [https://comatrix.eu/setup/ CoMatrix project] before.

== Description ==

OSCORE is a security protocol designed to provide end-to-end protection between endpoints communicating using CoAP.

A key exchange protocol does not exist OSCORE and the keys are pre-shared between Gateway and Client. However, there is ongoing work with key exchanges such as EDHOC or [https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-11 ACE-OSCORE]

=== Gateway ===

The Python library aiocoap provided the OSCORE functionality and was implemented in order for the gateway to talk in OSCORE

==== Imports ====

Following imports were added

from aiocoap.oscore_sitewrapper import OscoreSiteWrapper
from aiocoap.credentials import CredentialsMap
from plugtest_common import *
from aiocoap.cli.common import server_context_from_arguments, add_server_arguments

* The plugtest_common import was extracted from the aiocoap OSCORE plugtest and provides verification for external AADs and returning the security context.

==== Main ====

When starting the gateway, new parameters have been added to list the directory where the pre-shared secrets are held and sequence numbers will be saved. These sequence numbers are necessary for replay protection.

parser.add_argument("contextdir", help="Directory name where to persist sequence numbers and the location of the secrets", type=Path)

// Necessary to add these arguments provided by the aiocoap library in order for the server to start correctly. More info under aiocoap/cli/common.py
add_server_arguments(parser)

The context directory may contain two files:
* secrets.json
* settings.json
As per implementation it is sufficient to only have one of these files in the directory.

The format of the file is the following JSON:
{
"sender-id_hex": "01",
"recipient-id_ascii": "file",
"secret_ascii": "Correct Horse Battery Staple"
}

Important properties are:
* sender-id
* recipient-id
* secret

These three properties must be appended with either _hex or _ascii and have the values according to the suffix.

Assume that the file above was for the server and for our client we would need the following file:
{
"sender-id_ascii": "file",
"recipient-id_hex": "01",
"secret_ascii": "Correct Horse Battery Staple"
}

Notice how sender-id and recipient-id had to be swapped.
With these two secret files it is now possible to start a gateway and a client each using a different JSON file with the ids flipped.

For further information see [https://aiocoap.readthedocs.io/en/latest/stateofoscore.html#oscore-credentials aiocoap-OSCORE]

Loading these in the code was done in the following way - For testing purposes there were two pairs of credentials a / b and c / d whereas the first one is used for the test client and the latter for the gateway:

// Loading the pre-shared secrets
server_credentials = CredentialsMap()
// the first parameter states the name of the context in this case it's b but can be named in any way and the second parameter is the path to the folder e.g. the file would be located in /contextdir/b/settings.json
server_credentials[':b'] = get_security_context('b', args.contextdir / "b")
server_credentials[':d'] = get_security_context('d', args.contextdir / "d")

To enable OSCORE for the server now the following code was added/adjusted:
// root is the variable for the site
// Enable the site to talK OSCORE with the credentials loaded from before
root = OscoreSiteWrapper(root, server_credentials)
args.bind = bind
// Now we create a server context with arguments added
asyncio.Task(server_context_from_arguments(root, args))

'''USAGE:''' ./comatrix_gateway.py contextdir

// TODO How to add picture in

To test if the gateway actually talks in OSCORE the plugtest-client from the aiocoap library was adjusted to meet our needs for comatrix.

'''USAGE:''' ./unit-tests.py host contextdir

// TODO Picture

== Client ==
// Await docs

== Used Hardware ==

* Raspberry Pi 3B+ Model (CoMatrix Gateway)
* OpenLabs 802.15.4. radio module
* SAMR21-xpro (CoMatrix Client)
* Raspberry Pi 4 (Matrix Homeserver)

== References ==

* https://comatrix.eu
* https://aiocoap.readthedocs.io
* https://github.com/chrysn/liboscore

[[Category:Documentation]]

CoMatrix: OSCORE

2023-07-04T06:53:27Z

MArcilla: Created page with "== Summary == This documentation describes the usage of an application-layer protocol OSCORE to provide end-to-end protection between the [https://comatrix.eu/setup/architecture_and_testbed CoMatrix Gateway and CoMatrix Client]. == Requirements == * Operating system: ** Ubuntu 22.04 (Gateway) ** RIOT OS (Client) * Hardware In order to complete these steps, you must set up the [https://comatrix.eu/setup/ CoMatrix project] before. == Description == OSCORE is a se..."

== Summary ==

This documentation describes the usage of an application-layer protocol OSCORE to provide end-to-end protection between the [https://comatrix.eu/setup/architecture_and_testbed CoMatrix Gateway and CoMatrix Client].

== Requirements ==

* Operating system:
** Ubuntu 22.04 (Gateway)
** RIOT OS (Client)
* Hardware

In order to complete these steps, you must set up the [https://comatrix.eu/setup/ CoMatrix project] before.

== Description ==

OSCORE is a security protocol designed to provide end-to-end protection between endpoints communicating using CoAP.

A key exchange protocol does not exist OSCORE and the keys are pre-shared between Gateway and Client. However, there is ongoing work with key exchanges such as EDHOC or [https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-11 ACE-OSCORE]

=== Gateway ===

The Python library aiocoap provided the OSCORE functionality and was implemented in order for the gateway to talk in OSCORE

==== Imports ====

Following imports were added

from aiocoap.oscore_sitewrapper import OscoreSiteWrapper
from aiocoap.credentials import CredentialsMap
from plugtest_common import *
from aiocoap.cli.common import server_context_from_arguments, add_server_arguments

* The plugtest_common import was extracted from the aiocoap OSCORE plugtest and provides verification for external AADs and returning the security context.

==== Main ====

When starting the gateway, new parameters have been added to list the directory where the pre-shared secrets are held and sequence numbers will be saved. These sequence numbers are necessary for replay protection.

parser.add_argument("contextdir", help="Directory name where to persist sequence numbers and the location of the secrets", type=Path)

// Necessary to add these arguments provided by the aiocoap library in order for the server to start correctly. More info under aiocoap/cli/common.py
add_server_arguments(parser)

The context directory may contain two files:
* secrets.json
* settings.json
As per implementation it is sufficient to only have one of these files in the directory.

The format of the file is the following JSON:
{
"sender-id_hex": "01",
"recipient-id_ascii": "file",
"secret_ascii": "Correct Horse Battery Staple"
}

Important properties are:
* sender-id
* recipient-id
* secret

These three properties must be appended with either _hex or _ascii and have the values according to the suffix.

Assume that the file above was for the server and for our client we would need the following file:
{
"sender-id_ascii": "file",
"recipient-id_hex": "01",
"secret_ascii": "Correct Horse Battery Staple"
}

Notice how sender-id and recipient-id had to be swapped.
With these two secret files it is now possible to start a gateway and a client each using a different JSON file with the ids flipped.

For further information see [https://aiocoap.readthedocs.io/en/latest/stateofoscore.html#oscore-credentials aiocoap-OSCORE]

Loading these in the code was done in the following way - For testing purposes there were two pairs of credentials a / b and c / d whereas the first one is used for the test client and the latter for the gateway:

// Loading the pre-shared secrets
server_credentials = CredentialsMap()
// the first parameter states the name of the context in this case it's b but can be named in any way and the second parameter is the path to the folder e.g. the file would be located in /contextdir/b/settings.json
server_credentials[':b'] = get_security_context('b', args.contextdir / "b")
server_credentials[':d'] = get_security_context('d', args.contextdir / "d")

To enable OSCORE for the server now the following code was added/adjusted:
// root is the variable for the site
// Enable the site to talK OSCORE with the credentials loaded from before
root = OscoreSiteWrapper(root, server_credentials)
args.bind = bind
// Now we create a server context with arguments added
asyncio.Task(server_context_from_arguments(root, args))

USAGE: ./comatrix_gateway.py contextdir

// TODO How to add picture in

To test if the gateway actually talks in OSCORE the plugtest-client from the aiocoap library was adjusted to meet our needs for comatrix.

USAGE: ./unit-tests.py host contextdir

// TODO Picture

== Client ==
// Await docs

== Used Hardware ==

* Raspberry Pi 3B+ Model (CoMatrix Gateway)
* OpenLabs 802.15.4. radio module
* SAMR21-xpro (CoMatrix Client)
* Raspberry Pi 4 (Matrix Homeserver)

== References ==

* https://comatrix.eu
* https://aiocoap.readthedocs.io
* https://github.com/chrysn/liboscore

[[Category:Documentation]]