Raspberry Pi 5 sans réseau : un paquet de connaissances empoisonné, mais correctement signé, passe tous les contrôles

Que devient un assistant IA local lorsqu'il vit sur un appareil sans réseau, mais qu'on doit pourtant pouvoir lui faire confiance ? Les chercheurs Georgios Feredzakis et Alexandros Papaspiridis ont testé la question sur un Raspberry Pi 5 : un RAG entièrement local sous isolation réseau, trois tailles de Qwen2.5 (1.5B, 3B, 7B), trois tailles de contexte et 300 questions de SQuAD 2.0. Verdict : certains mécanismes de protection fonctionnent presque parfaitement, mais la défense la plus évidente, la signature numérique, se révèle insuffisante.

Cinq modes de connectivité et des paquets de connaissances à la place du cloud

La plupart des déploiements d'IA générative dans l'IoT partent du principe que le cloud est à portée de main. Or les appareils réels fonctionnent souvent par intermittence, dans des périmètres fermés, ou carrément sans connexion. Les auteurs proposent pour ce cas une échelle de connectivité C0–C4, une taxonomie des mécanismes de confiance au moment de l'inférence et un canal de mise à jour pour les modes déconnectés : des paquets de connaissances signés et versionnés. L'appareil reçoit un nouveau paquet, le vérifie, et ne le raccorde qu'ensuite à la base dans laquelle le modèle va chercher son contexte.

Où la confiance tient, et où elle ne tient pas

Le premier mécanisme est une passerelle fondée sur le score de pertinence des fragments retrouvés, calibrée de manière empirique. Elle détecte presque parfaitement les requêtes dont le sujet est absent du corpus : AUROC de 0,97. Elle s'en sort nettement moins bien avec les questions sans réponse posées dans un domaine familier, avec un AUROC de 0,68. Ces questions ressemblent aux documents du corpus, et le score de recherche ne permet pas de les distinguer des questions normales.

Le second mécanisme est un validateur de sortie déterministe. Il transforme les réponses « bancales » en refus explicite, sans retirer au modèle une seule bonne réponse. Le vérificateur à base de NLI, que les auteurs ont aussi essayé, n'a apporté que peu de chose. Pour le 7B, 96 % des réponses de fond aux questions étiquetées « sans réponse » coïncidaient avec des fragments normalisés des passages retrouvés. Le modèle n'invente pas : il reprend du texte du contexte, même lorsque la réponse n'y figure formellement pas.

Une signature n'est pas une garantie de vérité

La partie la plus dure de l'étude porte sur les mises à jour. Les contrôles de signature et de hash seuls ont accepté 6 attaques sur 9 : retour à une version antérieure, rejeu, paquet expiré, clés révoquées, incompatibilité avec le modèle. La vérification multicouche a rejeté les 9 en environ 4,5 ms.

Mais un paquet empoisonné portant une signature valide a franchi tous les contrôles et privé le modèle de ses bonnes réponses sur les 30 questions ciblées. Les auteurs résument ainsi : l'intégrité établit la provenance, pas la vérité. La confiance dans le contenu doit être assurée chez l'éditeur, avant la signature, et non sur l'appareil. Ce test n'a été exécuté que sur le 3B ; le comportement du 7B reste une inconnue : dans l'expérience principale, il refusait plus souvent de répondre aux questions sans réponse.

Les chiffres clés de l'étude

• Plateforme : Raspberry Pi 5 avec 16 Go de mémoire, réseau isolé
• Modèles : Qwen2.5 1.5B, 3B, 7B ; trois tailles de contexte
• Données : 300 questions de SQuAD 2.0
• Passerelle basée sur le score de retrieval : AUROC de 0,97 pour les requêtes hors corpus, 0,68 pour les questions sans réponse dans le sujet
• Validateur de sortie déterministe : zéro bonne réponse perdue
• Vérificateur NLI : contribution modeste
• 7B : 96 % des réponses de fond aux questions sans réponse coïncidaient avec des fragments de passages
• 3B contre 7B : même proportion de réponses contenant la référence, pour une latence et une énergie estimée inférieures de plus de moitié ; une requête sur le 3B prend environ 22 s
• Pic de mémoire résidente à la fin de la requête : 6,3 / 9,4 / 13,6 Gio pour 1.5B / 3B / 7B
• Attaques sur les mises à jour : signature et hash en ont laissé passer 6 sur 9, la vérification en couches en a rejeté 9 sur 9 en ~4,5 ms
• Paquet signé empoisonné : a fait échouer les bonnes réponses sur 30 cibles sur 30

Ce que l'ingénieur doit en retenir

Pour les appareils hors ligne, mieux vaut choisir le 3B plutôt que le 7B : la qualité mesurée par le containment est identique, alors que la latence et l'énergie sont divisées par plus de deux. Le validateur de sortie coûte peu et mérite d'être installé d'emblée. Pour les mises à jour, il faut un compteur de version monotone, une date d'expiration, la révocation des clés et un contrôle de compatibilité avec le modèle : la signature seule ne suffit pas.

Des questions restent ouvertes : les auteurs reconnaissent que le détenteur de la clé et le retour arrière autorisé vers un paquet réputé fiable ne sont pas couverts, qu'ils n'ont trouvé aucun profil de mise à jour prêt à l'emploi pour le RAG, et que la clé de l'expérience a été générée sur l'appareil lui-même. Des participants à la discussion suggèrent de faire passer en plus un jeu fixe de questions de contrôle avant de basculer sur un nouveau paquet. Le temps pour cela existe : l'embedding d'un paquet sur le Pi prend environ 29 minutes.

Tous les chiffres se reproduisent en une seule commande, et le code ainsi que les sorties de chaque requête sont publiés.