Bienvenue sur Vittascience

Nous sommes ravis de vous accueillir 😊, Souhaitez-vous recevoir la newsletter mensuelle de Vittascience pour rester informé(e) des nouveautés, événements et contenus pédagogiques ?

loader

Kit cyber - Chapitre 4 : Echange de messages en clair

Premier chapitre du parcours Ecoute des communications du kit cyber


Dans un réseau, la communication suit souvent une organisation appelée client / serveur. Le client envoie une requête au serveur, par exemple pour demander une information, et le serveur lui répond avec les données correspondantes.
Avec deux cartes micro:bit, on peut reproduire ce fonctionnement : la première joue le rôle du client, en transmettant une donnée comme un identifiant ou un numéro de compte, et la seconde agit comme serveur, en renvoyant une réponse adaptée, par exemple un solde (argent sur un compte en banque).

Une communication client/serveur repose sur un principe simple : le client formule une demande et le serveur envoie une réponse adaptée. C’est ce modèle qui est utilisé dans la plupart des services numériques : lorsqu’on consulte une page Internet, par exemple, le navigateur agit comme client et interroge le serveur du site qui renvoie son contenu.
Dans notre activité, le client peut envoyer une information sensible, comme un identifiant ou un numéro de compte, et le serveur renvoie une donnée liée, comme un solde. Les messages échangés entre les deux micro:bits circulent alors directement, sans aucune protection particulière : ils sont envoyés en clair, c’est-à-dire que tout appareil capable de capter la communication peut les lire.
Ce fonctionnement est facile à mettre en place et permet de comprendre comment se déroulent les échanges numériques, mais il n’offre aucune garantie de confidentialité.

La carte client va jouer le rôle d'une application bancaire. Elle va pouvoir, en fonction de l'identifiant de l'utilisateur, demander au serveur, via un message radio, le solde de l'utilisateur. Les messages radio envoyés seront de la forme clé/valeur (variables name / value dans le code). La clé des messages servira à indiquer le type d’action à effectuer côté serveur, et la valeur contiendra les informations nécessaires pour effectuer l’action.
On va créer deux types d’actions (requêtes) :
  • demande_solde : cette requête est envoyée par le client et contient son identifiant. C’est ce type de messages que va écouter le serveur.
  • reponse_solde : cette requête est renvoyée par le serveur lorsqu’il a récupéré le solde à partir de l’identifiant fourni dans demande_solde, que le client va écouter.

Le client devra envoyer une requête demande_solde lorsqu’on appuiera sur son bouton A, et, une fois qu’il aura reçu son solde via reponse_solde, affichera ce dernier sur sa matrice de LED.
Il ne faudra pas oublier de configurer la communication radio pour que serveur et client communiquent ensemble correctement.

Attention - Pour tous les programmes de ce parcours, il faut configurer la radio en utilisant le bloc associé, afin de définir la taille des messages à 128 ou plus. Dans le cas inverse, les programmes risquent de ne pas fonctionner.



Si tu es bloqué :
  • Vérifie que le client envoie bien demande_solde avec l’identifiant du compte en valeur.
  • Sur la réception, ne traite que les messages dont la clé (name) est reponse_solde.
  • Tu peux afficher name et value dans la console pour vérifier ce que renvoie le serveur

La carte serveur va représenter le serveur de la banque.
La carte stocke deux listes : l’une contient les identifiants des clients, l’autre les soldes associés. Pour retrouver le solde d’un client, on cherche d’abord la position de son identifiant dans la première liste. Une fois cette position trouvée, on regarde à la même place dans la deuxième liste : on y trouve alors le solde correspondant.
La carte va ensuite devoir écouter les messages radio entrants, et lorsque la clé du message correspondra à demande_solde, la carte devra vérifier si l'identifiant donné (valeur du message) correspond à l'un des identifiants de la liste, et, si c'est le cas, renvoyer un message avec pour clé reponse_solde et valeur le solde correspondant à l'identifiant. Si l'identifiant est invalide, on pourra renvoyer un message reponse_solde avec une valeur spéciale, comme par exemple -999 pour indiquer que l'identifiant n'est pas enregistré ou autre.

Tableau listes

Un exemple de contenu des deux listes

Pour vérifier si un élément est présent dans une liste, il faut utiliser le bloc suivant :


bloc trouver occurence liste

Le problème avec ce bloc, c’est qu’il produit une erreur lorsque l’élément cherché n’est pas présent dans la liste. Cette erreur arrête le programme, et fait “crash” la carte. Il faut donc encapsuler ce bloc dans un bloc try / except. Ce dernier est capable de vérifier si une erreur se produit, et d’effectuer une action spéciale lorsque cela se produit :

blocs try / except



Si tu es bloqué :
  • Vérifie que les deux listes ont la même longueur et que chaque identifiant a bien son solde à la même position.
  • Quand un message demande_solde arrive, commence par chercher la position de l’identifiant dans la liste des identifiants.
  • Si tu trouves une position, renvoie reponse_solde avec le solde à cette position ; sinon, renvoie reponse_solde avec la valeur spéciale (par exemple -999).

Connecte les deux micro:bit (client et serveur) sur le même canal radio, puis lance les programmes. Sur la carte client, appuie plusieurs fois sur le bouton A pour envoyer des demandes de solde avec différents identifiants. Observe les réponses : lorsque l’identifiant existe dans la liste du serveur, le solde correspondant s’affiche sur la matrice de LED ; sinon, c’est la valeur spéciale (par exemple -999) qui apparaît pour signaler qu’aucun compte ne correspond.

Dans cette activité, nous avons simulé le fonctionnement d’une application bancaire avec deux cartes micro:bit :
  • le client envoie une requête avec son identifiant,
  • le serveur cherche l’information correspondante dans sa base (les listes),
  • puis il renvoie le solde au client.

On comprend ainsi comment fonctionne la logique des échanges client/serveur, qui est au cœur d’Internet et des services en ligne. Mais attention : dans notre exemple, les données circulent en clair. Cela signifie que n’importe qui, en écoutant la communication, pourrait voir passer des informations sensibles comme un numéro de compte ou un solde.

Pour aller plus loin :
  • Se renseigner sur le protocole HTTP et voir comment les requêtes (URL, paramètres, contenus de formulaires) peuvent circuler en clair sur le réseau.
  • Chercher les mots-clés « modèle client-serveur » et « requête / réponse » pour voir comment ce principe est utilisé dans la plupart des services en ligne.

Licence d'utilisation

Licence Creative Commons

Cette ressource est mise à disposition selon les termes de la Licence Creative Commons Attribution - Partage dans les Mêmes Conditions 2.0 France