Meshtastic - Revision history

Bertrik Sikken: /* Backend */

2025-09-01T21:06:31Z

Backend

← Older revision		Revision as of 21:06, 1 September 2025
Line 72:		Line 72:
	* Decoding works as follows:		* Decoding works as follows:
	** Decrypt with the pre-shared-key (this always work but might result in garbage)		** Decrypt with the pre-shared-key (this always work but might result in garbage)
	** ~~Attempt to decode according to the the protobuf~~ portnum~~+payload (meshtastic~~ '~~Data~~')		** Find packets with portnum 'private data'
	** ~~Check the port number~~		** Calculate MAC for all known secret passphrases. When finding a packet with matching MAC, it is almost certainly a packet generated by 'us'
	** ~~Check and remove checksum/MAC in~~ the ~~payload~~		** Match the device address against a list of known devices
	** ~~Process~~ the ~~citizen science data payload~~		** Check the unique packet id, check that it has increased since the last known packet received
	* If all of the steps above check out, consider it to be a valid packet		* If all of the steps above check out, consider it to be a valid packet
	* Check in a local cache if this is a duplicate packet and if so, ignore it		* Check in a local cache if this is a duplicate packet and if so, ignore it

Bertrik Sikken: /* Checksums */

2025-09-01T21:01:12Z

Checksums

← Older revision		Revision as of 21:01, 1 September 2025
Line 55:		Line 55:

	=== Checksums ===		=== Checksums ===
	The idea is to send the payload 'unencrypted', ~~e.g. not with an~~ additional layer ~~of encryption~~ on top of meshtastic ~~LongFast~~ encryption,		The idea is to send the payload 'unencrypted', which means without any additional encryption layer on top of the standard public LongFast meshtastic encryption,
	but to ~~add a kind of checksum that authenticates~~ the message.		but with a MAC (message authentication code) appended to the message.

	~~How LoRaWAN does this,~~ is ~~by prefixing the information payload with a 16-byte array containing context~~-data ~~(e.g~~. sender, ~~fport, fcnt, up/down), then calculating a CMAC-AES over~~ it ~~with the network key, then using 4 bytes of the result as MAC~~.		The MAC allows you to determine that the packet is really yours and not some other random private-data packet from another user.
			The MAC includes the sender address and unique packet id, so it will be different for different nodes and is resistant to replay attacks.

	~~In python this could look like this~~:		The MAC is derived as follows:
	~~<pre>~~		* blake2s algorithm over the following fields:
	~~from Crypto.Hash import CMAC~~		** passphrase encoded as ascii, without 0-terminator
	~~from Crypto.Cipher import AES~~		** sender address (little-endian)
			** packet id (little-endian)
	~~cmac = CMAC.new(key~~, ~~ciphermod=AES)~~		* the MAC determined as the last 4 bytes of the resulting blake hash
	~~cmac.update~~(~~message~~)

	~~# Get full CMAC result~~ (~~16 bytes~~)
	~~cmac_result = cmac.digest()~~

	~~# LoRaWAN uses only~~ the ~~first~~ 4 bytes as the ~~MIC~~
	~~mic = cmac_result[:4]~~
	~~</pre>~~

	~~How to do this in Arduino, chatgpt suggests:~~
	~~<pre>~~
	~~#include <Crypto.h>~~
	~~#include <AES.h>~~
	~~#include <AESCMAC.h>~~

	~~AES128 aes; // AES block cipher (128-bit key)~~
	~~AESCMAC cmac(aes); // CMAC using AES~~

	~~cmac.clear();~~
	~~cmac.setKey(key, sizeof(key));~~
	~~cmac.add(message, sizeof(message));~~
	~~cmac.finalize(cmac_result, sizeof(cmac_result));~~
	~~</pre>~~

	=== Backend ===		=== Backend ===

Bertrik Sikken: /* Packet structure */

2025-09-01T20:52:14Z

Packet structure

← Older revision		Revision as of 20:52, 1 September 2025
Line 117:		Line 117:
	Within the meshtastic protobuf:		Within the meshtastic protobuf:
	<pre>		<pre>
	[ portnum \| private-data \| flag ]		[ portnum (256:private-data) \| private-data \| ok-to-mqtt flag ]
	</pre>		</pre>
	The portnum indicates 'private data'. The private-data is not encrypted separately. The flag contains the ok-to-mqtt bit.		The portnum indicates 'private data'. The private-data is not encrypted separately. The flag contains the ok-to-mqtt bit.
Line 123:		Line 123:
	Within the private-data:		Within the private-data:
	<pre>		<pre>
	[ 4-byte message authentication code ~~\| citizen-science payload~~ ]		[ citizen-science payload \| 4-byte message authentication code ]
	</pre>		</pre>
	With respect to security coding:		With respect to security coding:
	* The payload is not encrypted, but it ~~prefixed~~ by a message authentication code (MAC)~~, to be determined exactly what algorithm~~		* The payload is not encrypted, but it suffixed by a message authentication code (MAC)
	* The MAC is only 32-bit, to keep the length manageable		* The MAC is only 32-bit, to keep the length manageable

	~~Could be something like (python):~~
	~~<pre>~~
	~~cipher = AES.new(key, AES.MODE_GCM, nonce=nonce, mac_len=4) # 4-byte auth tag~~
	~~ciphertext, auth_tag = cipher.encrypt_and_digest(message)~~
	~~</pre>~~
	~~or (ESP32):~~
	~~<pre>~~
	~~mbedtls_gcm_context gcm;~~
	~~mbedtls_gcm_init(&gcm);~~
	~~mbedtls_gcm_setkey(&gcm, MBEDTLS_CIPHER_ID_AES, key, 128); // 128-bit AES~~
	~~mbedtls_gcm_crypt_and_tag(&gcm, MBEDTLS_GCM_ENCRYPT,~~
	~~sizeof(plaintext), nonce, sizeof(nonce),~~
	~~NULL, 0, plaintext, ciphertext,~~
	~~sizeof(auth_tag), auth_tag);~~
	~~</pre>~~

	== Protocol ==		== Protocol ==

Bertrik Sikken: /* Checksums */

2025-09-01T20:44:39Z

Checksums

← Older revision		Revision as of 20:44, 1 September 2025
Line 55:		Line 55:

	=== Checksums ===		=== Checksums ===
	The idea is to send the payload 'unencrypted', e.g. not with an additional layer of encryption on top of meshtastic encryption,		The idea is to send the payload 'unencrypted', e.g. not with an additional layer of encryption on top of meshtastic LongFast encryption,
	but to add a kind of checksum that authenticates the message.		but to add a kind of checksum that authenticates the message.

Bertrik Sikken: /* Overall design */

2025-06-27T15:36:30Z

Overall design

← Older revision		Revision as of 15:36, 27 June 2025
Line 44:		Line 44:
	* citizen science nodes send data in meshtastic-compatible format, so packets can be routed accross the meshtastic network		* citizen science nodes send data in meshtastic-compatible format, so packets can be routed accross the meshtastic network
	* data is sent from the node typically every 5 minutes		* data is sent from the node typically every 5 minutes
	* data is ~~broadcasted~~ inside the network, until it reaches a node with a MQTT backend connection, typically within a maximum of 3 hops.		* data is broadcast inside the network, until it reaches a node with a MQTT backend connection, typically within a maximum of 3 hops.
	* data arriving at the MQTT server is picked up by a backend application, which can then process it further		* data arriving at the MQTT server is picked up by a backend application, which can then process it further

Bertrik Sikken: /* Meshcore */

2025-06-27T15:35:32Z

Meshcore

← Older revision		Revision as of 15:35, 27 June 2025
Line 35:		Line 35:

	== Meshcore ==		== Meshcore ==
	* https://flasher.meshcore.co.uk/		* web flasher https://flasher.meshcore.co.uk/
	* meshcore companion app https://meshcore.nz/		* meshcore companion app https://meshcore.nz/
			* meshcore map https://meshcore.co.uk/map.html
	* meshcore information https://meshcore.co.uk/		* meshcore information https://meshcore.co.uk/

Bertrik Sikken at 13:29, 27 June 2025

2025-06-27T13:29:48Z

← Older revision		Revision as of 13:29, 27 June 2025
Line 34:		Line 34:
	* write a backend/plugin for my sensor-data-bridge		* write a backend/plugin for my sensor-data-bridge

	~~Other stuff:~~		== Meshcore ==
	* ~~Should look into~~ meshcore ~~too:~~		* https://flasher.meshcore.co.uk/
	** meshcore companion app https://meshcore.nz/		* meshcore companion app https://meshcore.nz/
	** meshcore information https://meshcore.co.uk/		* meshcore information https://meshcore.co.uk/

	== Design ==		== Design ==

Bertrik Sikken: /* Intro */

2025-06-20T17:20:47Z

Intro

← Older revision		Revision as of 17:20, 20 June 2025
Line 33:		Line 33:
	* create a particulate matter sensor that sends meshtastic		* create a particulate matter sensor that sends meshtastic
	* write a backend/plugin for my sensor-data-bridge		* write a backend/plugin for my sensor-data-bridge

			Other stuff:
			* Should look into meshcore too:
			** meshcore companion app https://meshcore.nz/
			** meshcore information https://meshcore.co.uk/

	== Design ==		== Design ==

Bertrik Sikken: /* Packet structure */

2025-06-05T12:31:58Z

Packet structure

← Older revision		Revision as of 12:31, 5 June 2025
Line 113:		Line 113:
	[ portnum \| private-data \| flag ]		[ portnum \| private-data \| flag ]
	</pre>		</pre>
	The private-data is not encrypted separately		The portnum indicates 'private data'. The private-data is not encrypted separately. The flag contains the ok-to-mqtt bit.

	Within the private-data:		Within the private-data:

Bertrik Sikken: /* Packet structure */

2025-06-05T11:15:06Z

Packet structure

← Older revision		Revision as of 11:15, 5 June 2025
Line 117:		Line 117:
	Within the private-data:		Within the private-data:
	<pre>		<pre>
	[ ~~citizen-science payload \|~~ 4-byte message authentication code ]		[ 4-byte message authentication code \| citizen-science payload ]
	</pre>		</pre>
	With respect to security coding:		With respect to security coding:
	* Algorithm is AES-GCM		* The payload is not encrypted, but it prefixed by a message authentication code (MAC), to be determined exactly what algorithm
	* The payload is not encrypted, but it ~~suffixed~~ by a message authentication code (MAC)
	* The MAC is only 32-bit, to keep the length manageable		* The MAC is only 32-bit, to keep the length manageable
	* The nonce used to calculate the MAC is similar to the earlier used nonce, but with the 'extra nonce' data equal to some application-specific id

	Could be something like (python):		Could be something like (python):