Il était une fois un petit ESP32, installé dans une cave, qui voulait communiquer avec son copain sur le toit pour envoyer des données par 4G. Il parlait peu, donc il pouvait utiliser la norme radio LoRa. Elle est à bas débit, mais permet une portée bien plus grande qu’une modulation classique. Le problème, c’est qu’il parlait en clair, et que n’importe qui pouvait écouter ou pire : injecter de fausses données, voire corrompre le serveur distant.

Le protocole de communication à la mode est celui de Signal, utilisé aussi par WhatsApp et Messenger. Un autre protocole en vogue est WireGuard, dont l’objectif est d’offrir un VPN léger pour Linux, en s’appuyant sur un ensemble restreint de briques cryptographiques modernes et fortement recommandées, qui ne sont plus laissées au choix de l’utilisateur.

L’idée était donc de trouver une implémentation de ce type pour l’embarqué. Eh bien, je n’ai presque rien trouvé.

Sommaire

• Briques de base
• Le chiffrement symétrique
• Le hash
• “Password hashing” ou la création de clef à partir de mot de passe
• Chiffrement à clef publique
• Générateur d’aléatoire
• Signature
• Serial Guard, le protocole de communication
• Le rejeu
• Durée de session
• Envoi d’un seul message
• Travail en cours

Briques de base

TLS est la référence absolue pour tous les algos, mais c’est à vous de faire votre choix. Libsodium est une implémentation des derniers algos recommandés et fait le choix pour vous. Ces deux bibliothèques sont énormes et sont optimisées pour PC. Un professeur de cryptographie a écrit une série de tweets qui contient une petite lib qui reprend les algorithmes de libsodium en version auditable (https://tweetnacl.cr.yp.to/). Mais elle est lente.

Une autre personne écrit ce que je cherche : Monocypher. C’est un fichier .c avec les algo principaux de libsodium et qui compile en pur C sans dépendance ! C’est parfait pour mon besoin.

Cette bibliothèque fournit uniquement les briques de base, on est très loin d’un protocole Signal. Quand on parle de cryptographie, on pense à AES pour le chiffrement symétrique, à RSA pour le chiffrement à clef publique et la signature, aux hashs SHA1 ou SHA512 pour un hash de qualité cryptographique. Les propriétés nécessaires sont fascinantes mais cela ne dit pas comment bien les utiliser ensuite.

Le chiffrement symétrique

Il s’agit de chiffrer un bloc avec une clé de taille fixe. Le représentant le plus connu est AES, avec des clés de 128 ou 256 bits. On a un bloc, on a une clé, et on obtient un bloc plus ou moins aléatoire. AES utilise des modes (GCM, XTS, …) pour renforcer le mélange et garantir la sécurité selon différents contextes.

Ici, l’algorithme recommandé est ChaCha20. Pas besoin de mode externe : tout est prévu dans l’algorithme de base.

Au déchiffrement, la brique ne se pose pas de question : si la donnée a été altérée, le résultat le sera aussi.Il faut donc ajouter un protocole d’authentification, qui utilise la même clé et un hash pour vérifier l’intégrité. Les algorithmes classiques sont MAC, HMAC, mais il est facile de faire une erreur dans leur utilisation.

Monocypher utilise Poly1305 pour authentifier le message (AEAD – Authenticated Encryption with Associated Data). Son API combine XChaCha20 et Poly1305, ce qui évite de se poser des questions : en cas de modification du message chiffré, la fonction de déchiffrement renvoie une erreur explicite.

Cette fonction nécessite un NONCE ("Number used once"), qui doit être différent à chaque appel.

Le hash

Un hash prend un bloc de données, fait une grosse salade et rend un chiffre de taille fixe avec de bonnes propriétés crypto. Le but est d’avoir une empreinte de taille fixe pour un bloc de données, et qu’il soit impossible de forger un hash identique en modifiant un peu les données d’origine. En gros.

Le hash recommandé est BLAKE2b : “as secure as SHA-3 and as fast as MD5”. Il fait 256 ou 512 bits.

“Password hashing” ou la création de clef à partir de mot de passe

Lorsqu’un mot de passe est saisi, il n’est jamais utilisé tel quel : il est d’abord transformé en une valeur de taille fixe via une fonction de hachage. Pour contrer les attaques par force brute, on a commencé par appliquer des centaines d’itérations de SHA1, avant d’adopter des fonctions de hachage volontairement lentes, comme bcrypt ou scrypt. Le but étant justement d’éviter qu’elles soient rapides, contrairement aux fonctions de hachage classiques.

Aujourd’hui, Argon2 est recommandé.

Chiffrement à clef publique

L’image est souvent celle d’un cadenas ouvert : n’importe qui peut fermer le cadenas, mais seul le possesseur de la clef peut l’ouvrir. RSA a été le premier algorithme inventé avec cette propriété. Aujourd’hui, la mode est aux courbes elliptiques avec X25519.

La fonction principale est basée sur l’échange Diffie-Hellman (DH). C’est le truc magique de la crypto asymétrique.

DH(Clef publique de A, Clé privée de B) = DH(Clef publique de B, Clé privée de A) = N

Sans une clef privée, il est cryptographiquement impossible de retrouver N.

Comment créer une clef privée ? C’est simplement 32 octets très aléatoires. Toute la sécurité dépend de cela. On se rappelle de la faille Debian utilisant un générateur prévisible en 2008.

Générateur d’aléatoire

Pour faire de la cryptographie sérieusement, il faut un vrai générateur aléatoire de qualité cryptographique. Monocypher, par exemple, n’en fournit pas, car cela dépend trop du matériel utilisé. C’est donc à vous d'en fournir un correct.

Ne surtout pas utiliser random() ou rand() : ces fonctions ne sont pas prévues pour la sécurité. Elles offrent souvent à peine 32 bits d’entropie, ce qui signifie qu’elles peuvent générer des valeurs qui tournent en boucle après seulement 4 milliards de cas, ce qui est trivial à explorer pour un attaquant moderne.

Un bon générateur s’appuie sur des sources d’entropie, autrement dit, des phénomènes imprévisibles : le bruit du système, les délais entre événements, la température, etc. Ensuite, ces sources sont mélangées (souvent via un gros hash) pour produire des nombres avec des propriétés statistiques solides.

Par exemple, Linux collecte plein de métriques internes (activité réseau, mouvements de la souris, etc.) pour alimenter son générateur aléatoire /dev/urandom.

Côté matériel, certaines plateformes proposent un vrai générateur physique : il peut mesurer le bruit électrique à travers une diode via un convertisseur analogique-numérique (ADC), ou encore exploiter les légères variations de vitesse d’oscillateurs internes (anneaux d’inverseurs), qui sont ensuite mélangées avec des circuits comme des LFSR combinés via XOR.

Utilisez le générateur cryptographique fourni par votre plateforme (par exemple getrandom(), arc4random(), ou un TRNG matériel si vous êtes en embarqué).

Il ne faut pas se créer son propre générateur sans savoir exactement ce que l’on fait. Le pire étant de réutiliser des données (des clefs par exemple) pour générer d’autres nombres. On crée ainsi une énorme dépendance entre eux, qui n’ont plus rien d’aléatoire.

Les dernières failles des imprimantes Brother proviennent du fait que les mots de passe d’administration sont dérivés de leur numéro de série (!).

Signature

On a un bloc de données, on signe avec une clef privée, on vérifie la signature avec la clef publique.

Monocypher propose EdDSA.

Serial Guard, le protocole de communication

Il ne faut pas créer sa propre cryptographie, c’est trop facile de se tromper. C’est pourtant exactement ce que j’ai fait. La suite peut donc contenir des erreurs. L’idée est de créer un protocole léger de communication. Si des experts passent par là et voient une horreur, qu’ils n’hésitent pas à crier.

On a maintenant les blocs de base. Et il faut maintenant les agencer comme il faut. On veut que A communique avec B (Alice et Bob), sans que E puisse comprendre les messages, insérer des messages, modifier des messages, rejouer des messages, récupérer les messages dans le futur s’il a tout enregistré et récupérer les clefs privées.

Dans le monde de l’embarqué « simple », on communique avec des read et des write sur lien série. L’idéal est d’avoir à peu près la même API.

Il faut réduire au minimum l’échange d’informations préalable pour être le plus léger possible.

Je laisse de coté le "framing", c'est à dire la mise en paquet pour être envoyé sur un lien physique. Un lien série envoie des octets, serialguard fonctionne par paquets d'octet. Il faut reconstituer un paquet avant de l'envoyer dans la bibliothèque.

La base est d’avoir une clef privée chacun, à longue durée de vie. Cela permet de s’authentifier selon le principe : si c’est toujours la même clef depuis l’installation, c’est toujours le même pair : TOFU.

Si on a besoin de faire mieux, il faudrait qu’une « clef de confiance » signe cette clef. Mais on entre dans les méandres complexes d’une public key infrastructure, des certificats ou des web of trust type GPG.

Pour pouvoir tout de même changer une clef privée à long terme, tout en ayant de la sécurité pour éviter les man-in-the-middle, il faut garder un secret partagé dans tous les pairs. Cela peut être très compliqué sur un réseau de serveurs, mais ici, chaque boîtier est programmé au même endroit.

Il s’agit simplement d’un nombre de 32 octets aléatoire partagé par tous. C’est nommé pompeusement pre-shared key (PSK).

Il faudra éviter de la laisser traîner dans le code source.

Une clef de session est une clef temporaire, renouvelable. L’idée est d’utiliser la cryptographie asymétrique pour se mettre d’accord sur une clef symétrique.

Si on utilise le nombre généré par Diffie-Hellman (DH) directement, il est unique par pair de clefs privées : ce n’est pas top. On pourrait échanger des nombres aléatoires pour se mettre d’accord sur une clef symétrique, mais je veux limiter les échanges au minimum.

Pour cela, je vais utiliser une clef de session asymétrique, qui est l’invention du protocole Signal. Une fois la clef symétrique générée, la clef privée éphémère est jetée. Il sera impossible ensuite de déchiffrer la session, même dans le futur.

On commence donc par un échange de 2 clefs publiques : l’une à durée de vie longue et l’autre éphémère.
On croise les 8 clefs (2 publiques et 2 privées de chaque côté) dans 3 échanges DH, on trie les nombres pour avoir le même ordre des 2 côtés, et le résultat est donné à la fonction de hachage avec la PSK.

On a ainsi notre clef de session symétrique.

Le rejeu

Tant que la session est active, l’envoi d’un message précédent reste valide. Pour éviter cela, un NONCE est utilisé dans le chiffrement symétrique. C’est un nombre fourni quelconque mais qui ne doit jamais être identique d’un paquet à l’autre. Il peut être transmis avec le paquet, mais cela prend de la place.

J’ai choisi d’utiliser un simple compteur, cela évite de devoir se rappeler les NONCE passés pour éviter le rejeu.

Les liaisons n’étant pas fiables, un paquet peut être corrompu : il faut pouvoir décoder le paquet suivant. J’ai simplement choisi de tester les 10 nombres successifs en cas d’erreurs, avant d’échouer.

Durée de session

Une session doit être limitée en temps ou en quantité d’informations transmises. Il faut trouver un événement symétrique des 2 côtés pour redéclencher un handshake. J’ai laissé ce point à l’application. Cela pourrait être inclus dans le protocole réseau de plus haut niveau.

Envoi d’un seul message

Ce schéma ne couvre pas le cas d’envoi d’un seul message.

Dans l’Internet des objets, on pousse un message dans MQTT et on ne s’attend pas à une réponse. Cela serait bien plus pratique de pouvoir le faire. Il faut pouvoir faire l’envoi sans handshake préalable. Mais il faut tout de même envoyer les clefs publiques, ce qui prend de la place.

Le système a besoin de la clef publique du serveur et du PSK, et tout le reste est fourni en plus du chiffré (NONCE, clef publique, et clef publique éphémère) dans le message envoyé.

La différence est qu’il n’y a que 2 DH, et pas de clef éphémère du côté serveur.

Travail en cours

C’est encore un travail en cours. Il manque des tests sur le terrain et l’évaluation des performances sur plusieurs plateformes.

L’open source dans l’informatique embarquée se limitait historiquement aux systèmes d’exploitation et aux compilateurs. On connaît bien GCC, BusyBox et FreeRTOS. Puis, Arduino a fait son entrée dans le monde du semi-professionnel. Mais cela évolue rapidement. Trois domaines se développent avec des logiciels, et, parfois des produits open source, qui commencent à se croiser.

À part les liens Wikipedia, les sites pointés sont en anglais.

Drone

Le domaine des drones, principalement les quadcopters mais aussi les avions, rovers et même sous-marins (AUV), a vu naître des projets comme PX4 et ArduPilot. Ces firmwares d’autopilotes permettent un asservissement entre ce que l’on demande au drone et la réalité grâce à des centrales inertielles. Ils gèrent des tâches comme le quadrillage d’un secteur ou le retour automatique au point de départ, à l’aide de GPS ou de caméras de flux optique utilisant une technologie similaire à celle des souris. Les développements actuels se concentrent sur l’évitement automatique d’obstacles, comme les arbres.

PX4 repose sur le système d’exploitation temps réel NuttX, soutenu par la Fondation Apache. Ce système m’était encore inconnu jusqu’à récemment.

QGroundControl est un logiciel pour préparer des missions (points GPS, prises d’images, largages…), lire des journaux transmis par radio et configurer les drones sous PX4 ou ArduPilot, ainsi que pour mettre à jour leur firmware.

Le projet Pixhawk définit une plateforme matérielle supportée par ces deux firmwares. On en est à plus de six versions de FMU (“Flight management unit”), utilisant des processeurs STM32 avec des gyroscopes, accéléromètres, magnétomètres et baromètres, souvent avec des redondances. Les cartes comportent de nombreux connecteurs pour brancher les radiocommandes (plusieurs protocoles), les servos, les contrôleurs moteurs (ESC), les GPS, ainsi que des bus CAN utilisant des protocoles open source comme DroneCAN ou Cyphal.

Radio commande

Les ESC (Electronic Speed Controllers) transforment une commande de vitesse en une gestion complexe de trois signaux pour contrôler des moteurs synchrones. Le VESC Project propose un firmware open source, offrant des réglages avancés, comme la limitation du courant ou l’asservissement via des capteurs à effet Hall. Un programme Android permet de gérer des moteurs pour trottinettes ou voiturettes.

Dans le domaine des radiocommandes, le projet OpenTX, forké en EdgeTX, remplace le firmware des radiocommandes. RadioMaster, un outsider, utilise directement ces logiciels, contrairement aux fabricants haut de gamme plus conservateurs (Futaba, Spektrum, JR, Flysky, etc.). Ces firmwares permettent une personnalisation via des scripts Lua.

Pour les protocoles radio, plusieurs solutions propriétaires existent avec des portées annoncées de plus de 2 km. Cependant, un protocole ouvert, ExpressLRS, reposant sur LoRaWAN, permet des portées jusqu’à 5 km (en 2.4 GHz) ou 15 km (à 900 MHz). Les émetteurs et récepteurs bi-bandes commencent à apparaître.

Et robotique

Dans le domaine de la robotique, Gazebo est en train de devenir un simulateur et visualiseur polyvalent. Il repose sur le moteur de rendu OGRE et le moteur physique ODE. Il est intégré aux outils de développement de PX4 et même utilisé dans des concours de drones virtuels.

ROS2 (“Robot Operating System”) est un middleware généraliste basé sur un protocole Pub/Sub à faible latence, permettant à plusieurs ordinateurs de communiquer. Il tend à remplacer MAVLink, un protocole de commande plus léger, encore majoritaire dans le domaine des drones.

Les trois domaines (drones, robotique et radiocommande) se croisent de plus en plus. Les autopilotes permettent de gérer tous types de véhicules, tandis que des outils comme QGroundControl et ROS2 facilitent le développement de missions automatiques de plus en plus complexes.

L’informatisation et la mise en réseau des ordinateurs nous ont apporté beaucoup de choses formidables ces trente dernières années. Toute la culture musicale, cinématographique et encyclopédique est désormais à une portée de clic de quiconque. Téléphoner de n’importe où à n’importe qui tout autour de la terre est devenu quelque chose de tellement courant que plus personne ne s’en extasie. Et même si l’interlocuteurice s’exprime dans une autre langue ça n’est presque plus un problème avec les différents services de traduction en ligne que l’on peut avoir.

Ne parlons même pas de ce mini-ordinateur que presque tout le monde a désormais dans sa poche, équipé d’une chaîne hifi complète, d’un caméscope, d’un appareil photo d’excellente qualité et d’une connexion permanente au réseau mondial.

Nos logements sont désormais entièrement automatisables et pilotables à distance.

Je peux avoir de la musique ou la radio quand je veux dans mon casque sans fil grâce à la baladodiffusion.

Tous ces rêves numériques des années 90 se sont concrètement réalisés aujourd’hui, mais nous avons tout de même perdu quelque chose : le temps réel des interfaces

N. D. M. : par « temps réel » est ici utilisé dans le sens réponse immédiate humainement parlant, sans latence perceptible, réactives (voir les définitions Wiktionary ou Wikipedia pour temps réel qui, pour l’informatique, vont amener des exigences supplémentaires sur la durée maximale de réponse, la garantie du temps de réponse, etc.

Sommaire

• Le temps réel des interfaces
• Les systèmes sont devenus mous
• Revenons aux interfaces réactives
• Manifeste des interfaces temps réel
• Vers un Score-Interfaces-Temps-Réel ?
• Conclusion

Le temps réel des interfaces

En effet, avec la diffusion du numérique à tous les étages, les interfaces se sont ramollies. Aujourd’hui, lorsque nous appuyons sur un bouton pour jouer une musique, lancer une vidéo ou valider un formulaire sur Internet nous n’avons pas un retour immédiat de cet appui.

Il s’écoule souvent un temps non négligeable entre l’appui sur ledit bouton et la réaction du système. Ce problème ne se limite pas aux boutons bien sûr, c’est le même problème avec les branchements des chargeurs et autres interfaces USB, HDMI…

Nous ne sommes jamais immédiatement sûrs que l’action se soit bien passée. Si la réaction met trop de temps à venir (lancement de la musique, icône de mise en charge, validation du formulaire…) nous allons avoir tendance à réessayer au risque de se retrouver avec un « dys »fonctionnement anormal. Le bouton « play » de la musique est également le bouton pause, un ré-appui sur le bouton coupe la musique. Une absence de réaction de l’appareil au branchement va nous amener à débrancher puis rebrancher jusqu’à jeter le câble et en prendre un autre. Un ré-appui sur le bouton du formulaire va en renvoyer un autre, etc.

Nous parlons bien ici des interfaces qui ne sont pas en temps réel. Cela n’a rien à voir avec la puissance de calcul des machines. Les appareils des années 90 avaient beau avoir des interfaces temps réel, ils n’étaient pas puissants, beaucoup ne disposaient même pas de microprocesseurs.

Sur mon lecteur de cassettes audio, lorsque j’appuyais sur le bouton « play » le bouton émettait un « clic » bien distinctif et une petite vibration dans le doigt qui m’assurait que mon appui était bien pris en compte. Et si j’étais à la fin de la cassette le bouton remontait immédiatement, je savais instantanément que cela n’avait pas marché et qu’il fallait que j’appuie sur « eject » pour retourner la cassette… ou « rewind » pour rembobiner.

Pour lire ma cassette de petit ours brun, j’appuie sur le triangle et ça fait «clic» instantanément !

Alors que pour allumer la boite à histoires, il faut appuyer sur un bouton planqué sur le côté, et attendre plusieurs secondes que l’écran affiche un sourire. Ai-je bien appuyé ? Dois-je retenter ? Y a-t-il suffisamment de batterie pour que j’obtienne une réaction ? Et je ne parle même pas des deux boutons rotatifs rouge qui ne réagissent pas instantanément (en plus celui de gauche est à tourner pour le volume et celui de droite est à CLIQUER pour changer d’histoire…)

Les télévisions cathodiques des années 70-80 prenaient un certain temps à chauffer avant d’afficher l’image, mais l’appui sur le bouton « on » était marqué par un « clang » bien net, et nous savions que la télé était allumée, nous pouvions attendre d’avoir l’image. Les télés d’aujourd’hui mettent également du temps à s’allumer, mais elles ne signalent pas toujours la bonne réception de notre action sur la télécommande. Et ne parlons même pas des écrans d’ordinateur avec leur interface tactile à la noix (on doit pouvoir parler d'interfaces digitales pour le coup non ?) dont on ne voit même pas où se trouve le bouton.

Les systèmes sont devenus mous

Et cette mollesse les rend dysfonctionnels. Je ne compte plus le nombre de fois ou voulant ré-appuyer sur un bouton de validation, j’ai finalement appuyé sur un nouveau bouton venant d’apparaître sous mon doigt/curseur. Sans parler de tous ces systèmes électroniques portables qui prennent un temps dingue avant d’afficher quelque chose quand on appuie sur le bouton “ON”. Systèmes qui ne sont pas toujours réellement éteints d’ailleurs et dont l’appui long… les éteint !
Ne parlons même pas des systèmes avec boutons rotatifs de type « potards numériques » qui — non contents de générer des rebonds ou de sauter des pas — fonctionnent avec la même mollesse que les boutons « standard ».

Mais le problème ne se limite pas aux systèmes embarqués. Oh que non ! Toute l’informatique « desktop » et mobile est touchée. Les sites Web ont rouillé avec leurs méga-octets de bibliothèques javascript à télécharger avant de pouvoir appuyer sur le moindre bouton.

Le réseau étant désormais massivement sans fil (WiFi, GSM, 4g, 5g, gégé, …), l’on ne sait pas toujours pourquoi cette page met tant de temps à se charger. Attention, il n’est pas question ici de vitesse de connexion, mais plutôt d’absence d’indication claire de ce qui est en train de se passer : ai-je déconnecté, ou le lien réseau est-il tout simplement lent ?

Revenons aux interfaces réactives

C’est un problème d’ergonomie. Et l’ergonomie est visiblement toujours reléguée en fin de projet «tant qu’on a un truc qui marche». Cependant, on pourrait considérer que non, ça ne marche pas si l’interface est si lente à réagir.

Je suis persuadé que ce problème n’est pas une fatalité. Il est possible de revenir à des interfaces humain-machine qui soient vraiment temps réel.

Mais il faut que tout le monde s’y mette.

• Aux électroniciennes et électroniciens de mettre systématiquement le voyant (ou vibreur, ou son) qui va bien pour signaler le bon branchement du câble, et le bon appui sur le bouton.
• Aux développeuses et développeurs noyau de soigner l’ordonnanceur pour s’assurer que la partie interface soit bien traitée dans un temps acceptable (moins de 100 ms ?).
• Aux développeuses et développeurs d’applis de considérer un temps de réaction trop long des interfaces comme un bug qu’il faut corriger.
• Aux utilisatrices et utilisateurs de ne plus accepter un seul ralentissement de l’interface et remonter systématiquement le problème comme un bug et/ou ne pas acheter/utiliser le produit.

Manifeste des interfaces temps réel

Voici donc une proposition/un manifeste de règles pour des interfaces temps réel :

1. Toute action humaine (appui ou clic-toucher sur un bouton, branchement d’un câble…) doit être validée par un retour en moins de 100 ms par un visuel, un son ou une vibration.
2. Si le système est bloqué l’utilisateurice doit le savoir. On doit pouvoir faire la différence entre un blocage et un temps de chargement. Un genre de watchdog de l’ergonomie.
3. On peut certainement ajouter d’autres règles quand on fera des audits ITR (Interfaces Temps Réels) dans les bureaux d’études et de développement des grosses boites.

Vers un Score-Interfaces-Temps-Réel ?

Évidement, il est impossible que ces règles s’appliquent du jour au lendemain sur tous les appareils et logiciel du marché. On pourrait inventer un système de notation, à l’image du nutri-score mais pour les interfaces. Par exemple le SITR pour Score-Interfaces-Temps-Réel et développer une appli pour pouvoir récupérer le score des produits qu’on utilise.
Appli qui aurait le culot d’avoir un mauvais score histoire de faire causer.

Conclusion

Pour conclure sur ce manifeste décousu :

✊🏼 Oui l’ergonomie est importante !
✊🏽 Oui un temps de réaction trop long est un BUG !
✊🏿 Oui il faut que ça change !