Meshcore-sensor-net - Revision history

Bertrik Sikken: /* Progress */

2026-03-25T12:07:14Z

Progress

← Older revision		Revision as of 12:07, 25 March 2026
Line 34:		Line 34:
	* I understand the meshcore packet structure		* I understand the meshcore packet structure
	* Using an stm32wle5 board (has an sx1262-like built in), we can send a valid group-data packet which is understood by repeaters and repeated		* Using an stm32wle5 board (has an sx1262-like built in), we can send a valid group-data packet which is understood by repeaters and repeated
			* Initial Arduino gateway code for an esp32-s3 seeed board

	Todo:		Todo:
	* Implement the gateway part, the plan is to use a S3/SX1262 seeed board.
	* Write the backend part: listen to MQTT and respond with a valid packet		* Write the backend part: listen to MQTT and respond with a valid packet
	* Process the backend packet on the sensor node		* Process the backend packet on the sensor node

Bertrik Sikken: /* Introduction */

2026-03-25T12:06:15Z

Introduction

← Older revision		Revision as of 12:06, 25 March 2026
Line 22:		Line 22:
	* https://jacksbrain.com/2026/01/a-hitchhiker-s-guide-to-meshcore-cryptography/		* https://jacksbrain.com/2026/01/a-hitchhiker-s-guide-to-meshcore-cryptography/

	Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they ~~can~~'t inspect the encrypted part).		Meshcore repeaters are relatively "dumb", they just forward anything that resembles a packet (they dont't inspect the encrypted part).

	The idea is basically:		The idea is basically:

Bertrik Sikken: /* Packet structure */

2026-03-23T12:08:22Z

Packet structure

← Older revision		Revision as of 12:08, 23 March 2026
Line 99:		Line 99:
	** Fields included in hash: application name, deviceid (big endian)		** Fields included in hash: application name, deviceid (big endian)
	* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). Only the generated hash key is written to non-volatile storage of the sensor.		* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). Only the generated hash key is written to non-volatile storage of the sensor.

			In short:
			* Citizen science data is extended with a blake2s 4-byte MAC, based on the deviceid and a counter, calculated using a application/device-specific key
			* Citizen science data is encrypted on the meshcore level using AES128 (CBC mode) with a key based on the meshcore channel name

	== Software ==		== Software ==

	See https://github.com/bertrik/meshcore-sensor-net		See https://github.com/bertrik/meshcore-sensor-net

Bertrik Sikken at 12:23, 19 March 2026

2026-03-19T12:23:31Z

@@ Line 29: / Line 29: @@
 At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.
 The backend software processes the data payload and sends back an acknowledgement packet back over the (best) path that it received the message on. When this reaches the sensor node, the sensor node knows the most efficient way to reach the gateway node and uses a "direct" packet. Every now and then it expects a kind of acknowledgement packet back from the server, to know that messages are still coming through. This is actually a bit similar to how LoRaWAN works.
 == Investigation ==

Bertrik Sikken: /* Packet structure */

2026-03-16T12:15:41Z

Packet structure

← Older revision		Revision as of 12:15, 16 March 2026
Line 88:		Line 88:
	** Blake2s hash with key, where key = application secret		** Blake2s hash with key, where key = application secret
	** Fields included in hash: application name, deviceid (big endian)		** Fields included in hash: application name, deviceid (big endian)
	* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). ~~The resulting~~ key is written to non-volatile storage of the sensor.		* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). Only the generated hash key is written to non-volatile storage of the sensor.

	== Software ==		== Software ==

	See https://github.com/bertrik/meshcore-sensor-net		See https://github.com/bertrik/meshcore-sensor-net

Bertrik Sikken: /* Packet structure */

2026-03-16T12:14:37Z

Packet structure

← Older revision		Revision as of 12:14, 16 March 2026
Line 70:		Line 70:
	* Channel hash: 1 byte		* Channel hash: 1 byte
	* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format		* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format
	* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#~~meshcore-sensor-net~~')		* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#sensornet')

	Citizen science payload structure (big endian):		Citizen science payload structure (big endian):

Bertrik Sikken: /* Introduction */

2026-03-06T16:56:02Z

Introduction

← Older revision		Revision as of 16:56, 6 March 2026
Line 20:		Line 20:
	* Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py		* Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py
	* Meshcore source: https://github.com/meshcore-dev/MeshCore/tree/main/src		* Meshcore source: https://github.com/meshcore-dev/MeshCore/tree/main/src
			* https://jacksbrain.com/2026/01/a-hitchhiker-s-guide-to-meshcore-cryptography/

	Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).		Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).

Bertrik Sikken: /* Design */

2026-03-05T11:45:45Z

Design

← Older revision		Revision as of 11:45, 5 March 2026
Line 49:		Line 49:

	== Design ==		== Design ==

			=== Communication scheme ===
			The sensor sends measurements.
			The backend returns ACKs, with preferred path information to reach a gateway.
			Not every measurement is ACKed, to keep traffic down (like LoRaWAN does), but only every x messages (say 16).

			Escalation ladder when the sensor misses ACKs (or when the path to the gateway is lost):
			* When expecting ACKs, just send couple more (re)tries along the last known path, e.g. enable a kind of 'ACK wanted' flag
			* On start-up, try a quick-start with a zero-hop direct message, to probe if the gateway is perhaps within range of the sensor
			* On start-up, if the quick-start did not work, send a flood message (with larger network impact)
			To be worked out further.

			=== Packet structure ===
	The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".		The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".
	~~Initially flood mode, normally direct mode.~~

	Meshcore packet structure from sensor:		Meshcore packet structure from sensor:
Line 59:		Line 71:
	* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#meshcore-sensor-net')		* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#meshcore-sensor-net')

	Citizen science payload structure:		Citizen science payload structure (big endian):
	* 4 bytes deviceid		* 4 bytes deviceid
	* 4 bytes counter		* 4 bytes counter
Line 67:		Line 79:
	Security:		Security:
	* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload		* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload
	* The citizen science data is not secret, it is encrypted with a key derived from the channel name ('#~~meshcore-sensor-net~~'), but we do add a cryptographic checksum to recognize authentic messages belonging to a specific application and device		* The citizen science data is not secret, it is encrypted with a key derived from the channel name (e.g. '#sensornet'), but we do add a cryptographic checksum to recognize authentic messages belonging to a specific application and device
	* The checksum is calculated using the blake2s algorithm, calculated as follows:		* The checksum is calculated using the blake2s algorithm, calculated as follows:
	** Blake2s hash with key (32-bytes)		** Blake2s hash with key (32-bytes)
	** Fields included in hash: deviceid, counter, citizen science data		** Fields included in hash: deviceid, counter, citizen science data
	** We retain 4 bytes of the hash		** We retain 4 bytes of the hash to use as the MAC
	* The hash key itself ~~also~~ calculated as follows:		* The hash key itself calculated, as follows:
	** Blake2s hash with key, where key = application secret		** Blake2s hash with key, where key = application secret
	** Fields included in hash: application name, deviceid		** Fields included in hash: application name, deviceid (big endian)
	* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage of the sensor.		* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage of the sensor.

Bertrik Sikken: /* Meshcore security */

2026-03-02T23:21:32Z

Meshcore security

← Older revision		Revision as of 23:21, 2 March 2026
Line 43:		Line 43:
	Encryption of the payload is done using the key:		Encryption of the payload is done using the key:
	* Payload is padded with 0 to multiple of 16		* Payload is padded with 0 to multiple of 16
	* Encrypted using AES ECB mode, initialised with the key		* Encrypted using AES-128 ECB (!) mode, initialised with the key

	The 2-byte MAC is calculated over the encrypted payload, using the key:		The 2-byte MAC is calculated over the encrypted payload, using the key:

Bertrik Sikken: /* Meshcore security */

2026-03-02T20:31:06Z

Meshcore security

← Older revision		Revision as of 20:31, 2 March 2026
Line 33:		Line 33:
	=== Meshcore security ===		=== Meshcore security ===

	The 16-byte channel key is derived from the channel name, as follows ~~(python code)~~		The 16-byte channel key is derived from the channel name, as follows:
	key = hashlib.sha256(name.encode('utf-8')).digest()[0:16]		key = hashlib.sha256(name.encode('utf-8')).digest()[0:16]
	where 'name' is the channel name, including the '#'		where 'name' is the channel name, including the '#'

	The 1-byte channel hash is derived from the channel key, as follows		The 1-byte channel hash is derived from the channel key, as follows:
	hash = hashlib.sha256(key).digest()[0]		hash = hashlib.sha256(key).digest()[0]
	where 'key' is the byte array containing the key		where 'key' is the byte array containing the key

			Encryption of the payload is done using the key:
			* Payload is padded with 0 to multiple of 16
			* Encrypted using AES ECB mode, initialised with the key

			The 2-byte MAC is calculated over the encrypted payload, using the key:
			mac = sha256-hmac(payload)[0:2]

	== Design ==		== Design ==