Définitions #
- XBee® : la famille de modules radio actuellement utilisés par Digi International .
- Beenode : un nœud du réseau Beechat. Il se compose d’un routeur XBee actif dans le réseau. Le Beenode est simple s’il ne fait que rediriger des données (comme un relais), et complexe s’il envoie aussi des données (comme un utilisateur final).
- Beechat Address (BA) : un tableau de 12 octets calculé à partir de BLAKE3(DilithiumPublicKey).
- NodeID : un champ modifiable par l’utilisateur dans la radio XBee, visible par les autres Beenodes.
- BLAKE3 : l’algorithme de hachage utilisé
- Dilthium : l’algorithme de signature numérique asymétrique post-quantique. Chaque utilisateur dispose d’une clé privée pour chaque clé publique.
- Kyber : l’algorithme d’échange de clé asymétrique post-quantique. Chaque utilisateur dispose d’une clé privée pour chaque clé publique.
- secretKey : une clé secrète créée avec une clé publique Kyber.
- shareableKey : une clé qui peut être partagée publiquement. Il s’agit d’une clé secrète encapsulée. Seul le propriétaire de la clé privée Kyber peut la déchiffrer et extraire la clé secrète.
Inscription sur le réseau #
Notre adresse Beechat (BA) est un tableau de 12 octets calculé à partir de BLAKE3 (DilithiumPublicKey). Lors de l’utilisation d’un clip Beechat, nous définissons le NodeID de notre module XBee sur notre adresse Beechat.
Lors de l’inscription sur l’application Beechat, notre nœud envoie une diffusion à tous les nœuds joignables sur le réseau de notre BA .
D’autres appareils stockeront notre registrationString dans leur liste de tableaux de nœuds non confirmés.
Contact non confirmé #
Pour ajouter un contact, nous devons d’abord avoir reçu le BA de quelqu’un d’autre. Lors de l’actualisation de la liste des périphériques, nous pouvons trouver une adresse matérielle et une adresse d’ID de nœud dans la liste des périphériques qui correspondent à un objet dans la liste de tableaux de nœuds non confirmés. Si leur NodeID correspond également au BA de la même registrationString, nous commençons un « Node Challenge ».
Beenode difficile #
Une fois qu’un NodeID correspond à une registrationString, notre Beenode défie ce Beenode distant pour savoir s’il possède la bonne clé privée Dilithium.
- Notre Beenode crée un nombre aléatoire de 32 octets (ou 256 bits) de long, puis nous le hachons avec BLAKE3. Il s’agit du hachage aléatoire.
- Notre Beenode envoie le randomHash au Beenode distant.
- L’application Remote Beenode doit signer le randomHash avec la clé privée Dilithium et nous renvoyer la clé publique signée randomHash + full Dilithium. (jusqu’à présent, nous n’avions qu’un hachage de la clé publique)
- Notre Beenode prend la clé publique Dilithium qui vient d’être reçue de la réponse et vérifie que le randomHash signé correspond au randomHash que nous avons envoyé. S’il correspond, l’identité a été entièrement vérifiée.
Echange de clés avec un Beenode distant #
Avant d’avoir un échange de clés avec un contact, nous devons les avoir vérifiés, et ils doivent nous avoir vérifiés. Un échange de clé est l’acte de notre Beenode et d’un Beenode distant s’accordant sur une clé AES-256 pour chiffrer les messages avant qu’ils ne soient envoyés sur le réseau. L’échange de clé peut être initié par le premier Beenode qui veut envoyer un message et se fait comme suit, dans cet exemple nous sommes les premiers à envoyer un message au Beenode distant :
- Le Beenode distant crée une paire de clés Kyber, signe la clé publique Kyber avec sa clé privée Dilithium et nous envoie la clé publique Kyber signée. Notre Beenode vérifie la clé publique Kyber avec la clé publique Dilithium du Beenode distant.
- Nous prenons la clé publique Kyber de Beenode distante et créons une clé secrète et une clé partageable.
- Nous envoyons la shareableKey au Beenode distant.
- Remote Beenode déchiffre la clé partageable avec sa clé privée Kyber et envoie la chaîne « AOK » signée Dilithium à notre nœud confirmant que l’échange de clé a réussi.
- Nous vérifions le message « AOK » avec la clé publique Dilithium. Si la vérification est réussie, notre Beenode et notre Beenode distant permettent d’envoyer des messages entre deux appareils sur le front-end.
- Tous les messages suivants sont chiffrés à l’aide de secretKey comme entrée dans un hachage BLAKE3 256 bits. Le hachage résultant est utilisé comme mot de passe AES-256.
Paquets #
Un paquet Digimesh peut contenir jusqu’à 73 octets de données. Nous divisons les paquets en sections contenant différents types de données afin qu’elles puissent être correctement traitées.
Structure des paquets
Taper | Numéro d’article | Taille totale | Hacher | Charge utile |
1 octet | 4 octets | 4 octets | 2 octets | 62 octets |
Types de paquets disponibles
Étiqueter | Valeur | La description |
MESSAGE_DATA | 0x1 | La charge utile contient une partie de message texte ou un message entier |
FILE_DATA | 0x2 | La charge utile contient une partie de fichier |
DP_KEY | 0x3 | Demande de clé publique Dilithium |
SIGNED_HASH | 0x4 | Réponse / RandomHash signé |
KP_KEY | 0x5 | Demander une clé publique Kyber signée |
CHIPHER | 0x6 | Retourner la clé partageable |
INFO | 0x7 | Dossier d’information |
FILE_NAME_DATA | 0x8 | La charge utile contient un nom de fichier |