CoMatrix: OSCORE - Revision history

Ikramer at 13:40, 28 November 2023

2023-11-28T13:40:32Z

← Older revision		Revision as of 13:40, 28 November 2023
Line 293:		Line 293:
	== Used Hardware ==		== Used Hardware ==

	* Raspberry Pi 3B+ ~~Model~~ (CoMatrix Gateway)		* [[Raspberry Pi Model B+ V1.2]] (CoMatrix Gateway)
	* OpenLabs ~~802~~.15.~~4. radio module~~		* OpenLabs [[Raspberry_Pi_802.15.4_radio_module]]
	* ~~SAMR21-xpro~~ (CoMatrix Client)		* [[Atmel SAM R21 Xplained Pro]] (CoMatrix Client)
	* (optional) Raspberry Pi 4 (Matrix Homeserver)		* (optional) [[Raspberry Pi 4 4G Model B]](Matrix Homeserver)

	== References ==		== References ==

MBasta: /* Adopt liboscore */

2023-07-04T21:35:16Z

Adopt liboscore

← Older revision		Revision as of 21:35, 4 July 2023
Line 134:		Line 134:
	The comatrix examples for the chat and the tempsensor both use the source code in the comatrix folder which handles the CoAP messaging. This is why we did not change the examples but rather the comatrix code to implement OSCORE centrally.		The comatrix examples for the chat and the tempsensor both use the source code in the comatrix folder which handles the CoAP messaging. This is why we did not change the examples but rather the comatrix code to implement OSCORE centrally.
	Because the liboscore is still in a very early state and wasn't maintained for about two years we rarely found working examples so the focus was set onto the file 'demo-server.c' within the test 'plugtest-server' within the riot-tests folder which is documented as [https://oscore.gitlab.io/liboscore/demo_plugtest_linux.html Demo: Running the OSCORE plug test server on RIOT native ].		Because the liboscore is still in a very early state and wasn't maintained for about two years we rarely found working examples so the focus was set onto the file 'demo-server.c' within the test 'plugtest-server' within the riot-tests folder which is documented as [https://oscore.gitlab.io/liboscore/demo_plugtest_linux.html Demo: Running the OSCORE plug test server on RIOT native ].
	This code makes use of threading and mutex because it also acts as a server which we don't need because the chat and tempsensor examples only act as clients. We ~~needed~~ to ~~remvove~~ those parts and only use the functions for preparing and encrypting the OSCORE message.		This code makes use of threading and mutex because it also acts as a server which we don't need because the chat and tempsensor examples only act as clients. We have to work around those parts and only use the functions for preparing and encrypting the OSCORE message.

	First we added the includes to oscore		First we added the includes to oscore

MBasta: /* Setup the build stack */

2023-07-04T21:34:17Z

Setup the build stack

← Older revision		Revision as of 21:34, 4 July 2023
Line 119:		Line 119:
	First, the liboscore project has to be cloned locally with the recursive parameter so that it contains RIOT-OS itself. This can be achieved by following the steps provided in [https://oscore.gitlab.io/liboscore/demo_common.html Common set-up instructions for RIOT-based demos]		First, the liboscore project has to be cloned locally with the recursive parameter so that it contains RIOT-OS itself. This can be achieved by following the steps provided in [https://oscore.gitlab.io/liboscore/demo_common.html Common set-up instructions for RIOT-based demos]
	The folders 'comatrix', 'example_comatrix_chat' and 'example_comatrix_tempsensor' from the Comatrix client directory then have to be copied into the folder 'liboscore/tests/riot-tests/'.		The folders 'comatrix', 'example_comatrix_chat' and 'example_comatrix_tempsensor' from the Comatrix client directory then have to be copied into the folder 'liboscore/tests/riot-tests/'.
	Because the RIOT-OS is now different in relation to ~~the code~~ the Makefile has to be adapted.		Because the RIOT-OS code is now in a different location in relation to the Makefile, it has to be adapted.

	Remove this line:		Remove this line:
Line 129:		Line 129:
	The project can then be built by using		The project can then be built by using
	make all		make all


	=== Adopt liboscore ===		=== Adopt liboscore ===

MBasta: /* Adapt liboscore */

2023-07-04T21:29:18Z

Adapt liboscore

← Older revision		Revision as of 21:29, 4 July 2023
Line 131:		Line 131:


	=== ~~Adapt~~ liboscore ===		=== Adopt liboscore ===

	The comatrix examples for the chat and the tempsensor both use the source code in the comatrix folder which handles the CoAP messaging. This is why we did not change the examples but rather the comatrix code to implement OSCORE centrally.		The comatrix examples for the chat and the tempsensor both use the source code in the comatrix folder which handles the CoAP messaging. This is why we did not change the examples but rather the comatrix code to implement OSCORE centrally.
	Because the liboscore is still in a very early state and wasn't maintained for about two years we rarely found working examples so the focus was set onto the 'plugtest-server' ~~code~~ within the riot-tests folder which is documented as [https://oscore.gitlab.io/liboscore/demo_plugtest_linux.html Demo: Running the OSCORE plug test server on RIOT native ].		Because the liboscore is still in a very early state and wasn't maintained for about two years we rarely found working examples so the focus was set onto the file 'demo-server.c' within the test 'plugtest-server' within the riot-tests folder which is documented as [https://oscore.gitlab.io/liboscore/demo_plugtest_linux.html Demo: Running the OSCORE plug test server on RIOT native ].
	This code makes use of threading and mutex because it also acts as a server which we don't need because the chat and tempsensor examples only act as clients. We needed to remvove those parts and only use the functions for preparing and encrypting the OSCORE message.		This code makes use of threading and mutex because it also acts as a server which we don't need because the chat and tempsensor examples only act as clients. We needed to remvove those parts and only use the functions for preparing and encrypting the OSCORE message.

Line 286:		Line 286:
	return(len);		return(len);
	}		}


	=== Current status ===		=== Current status ===

MBasta: /* Current status */

2023-07-04T21:26:37Z

Current status

← Older revision		Revision as of 21:26, 4 July 2023
Line 289:		Line 289:

	=== Current status ===		=== Current status ===

			As we are facing issues regarding the liboscore code that lacks maintenance and documentation we have to deep dive into the functions.
			After these issues are resolved the remaining implementation is assumed to be straight forward for the other comatrix_* functions.

	== Used Hardware ==		== Used Hardware ==

MBasta at 21:23, 4 July 2023

2023-07-04T21:23:49Z

← Older revision		Revision as of 21:23, 4 July 2023
Line 286:		Line 286:
	return(len);		return(len);
	}		}


			=== Current status ===

	== Used Hardware ==		== Used Hardware ==

MBasta: /* Adapt liboscore */

2023-07-04T21:23:12Z

Adapt liboscore

@@ Line 170: / Line 170: @@
   };
   int16_t secctx_d_change = 0;
 == Used Hardware ==

MBasta: /* Adapt liboscore */

2023-07-04T21:16:33Z

Adapt liboscore

← Older revision		Revision as of 21:16, 4 July 2023
Line 156:		Line 156:
	static struct oscore_context_primitive_immutables immutables_d = {		static struct oscore_context_primitive_immutables immutables_d = {
	.common_iv = COMMON_IV,		.common_iv = COMMON_IV,

	.recipient_id_len = 0,		.recipient_id_len = 0,
	.recipient_key = RECIPIENT_KEY,		.recipient_key = RECIPIENT_KEY,

	.sender_id_len = 1,		.sender_id_len = 1,
	.sender_id = "\x01",		.sender_id = "\x01",
Line 170:		Line 170:
	};		};
	int16_t secctx_d_change = 0;		int16_t secctx_d_change = 0;



	== Used Hardware ==		== Used Hardware ==

MBasta: Zwischenspeichern

2023-07-04T21:16:10Z

Zwischenspeichern

@@ Line 17: / Line 17: @@
 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]
+The keys are pre-shared between the client and the gateway because there is no key exchange protocol in OSCORE itself. However, there is ongoing work with key exchange protocols 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
+The Python library aiocoap provides the OSCORE functionality and was used in order for the gateway to understand OSCORE within CoAP.
 === Imports ===
-Following imports were added
+The following imports were added
   from aiocoap.oscore_sitewrapper import OscoreSiteWrapper
@@ Line 111: / Line 111: @@
 == Client ==
-// Await docs
 == Used Hardware ==

MArcilla: /* Gateway */

2023-07-04T07:31:00Z

Gateway

← Older revision		Revision as of 07:31, 4 July 2023
Line 95:		Line 95:
	'''USAGE:''' ./comatrix_gateway.py contextdir		'''USAGE:''' ./comatrix_gateway.py contextdir

	~~// TODO How to add picture in~~		[[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.		To test if the gateway actually talks in OSCORE the plugtest-client from the aiocoap library was adjusted to meet our needs for comatrix.
Line 101:		Line 101:
	'''USAGE:''' ./unit-tests.py host contextdir		'''USAGE:''' ./unit-tests.py host contextdir

	~~// TODO Picture~~		[[File:Unittest-OSCORE.png]]

	=== Wireshark Capture ===		=== Wireshark Capture ===